Talk:Pascal (programming language)
Annoucement
I am tired of the time it takes to keep misinformation and general destruction from happening to this page. Let someone else do it.
When I first came here, this page hardly represented Pascal. It had misinformation, and had been largely hijacked by one group for their own particular language, which wasn't even compatible with the original Pascal.
I must admit I have never been wild about the Wikipedia concept in general. People who read a Pascal book yesterday think they now know enough to start rewriting this page. I can put a lot of work into the page, only to have it changed around by some user who feels they don't need to even provide a comment as to what they have done.
What Wikipedia does in general is follow the same level of information or misinformation as occurs in the common public mind. In the case of Pascal, the result is not good, and we find only what we already know: that Pascal has been misinformed almost to death. An encyclopedia is supposed to inform the population, not sink to its lowest common denominator.
I have been sucessful in cleaning this page up, and keeping it clean. I suspect, but don't know, that this is either tolerated or held in contempt. I don't see much (if any) positive feedback. What I have realized is simply that you can hold back the ocean if you are willing to perform that function constantly, but you lose the battle whenever you stop.
So Wikipedia is supposed to be self healing, and reliant on no one person. So its time for this page to rely on someone else.
The "quick synopsis"
For Mr. Weel, the short blurb was fine, but needs the following fixes.
1. Correct the spelling errors.
2. The date of appearance is wrong (or perhaps you can be more specific as to what event you are talking about?).
3. The designer is Wirth. Please do proper research before making significant changes to the page.
4. Major implementations/dialects: There are already too many wars over this page without "choosing favorites". There were several implications in your lists, for instance that other implementations were "minor", that these are the only important dialects, etc.
Since it seems ridiculous to list all of them in such a synopsis, I think it makes the most sense to leave these items out.
Thank you.
Tex and "Web"
The statement "tex was written in web, which was borrowed from Pascal" is highly misleading. Web is not a language, it is basically a system for annotating Pascal source code so that it is self documenting. Web is not compiled. In order to compile it, you extract the Pascal source code, and compile that.
I have the source for Tex in Pascal, after "extraction". Its fairly normal Pascal source (although, contrary to the myth that most Tex users believe, it is not, in fact, written to any sort of "standard" Pascal -- it is very much dependent on a particular installation).
The new statement, tex is written in Pascal, is better both because that is accurate, although simplified, and because, this being an introduction to Pascal, people don't need to get into the vast complexity of tex to just get to the basic subject at hand: Pascal.
Divisions
I added a "divisions" heading after the discussions on standard. There have been various "tug of wars" over which dialect of Pascal should be considered the "offical" one, some opining that it should be the ISO standard, some that it should be the Pascal dialect that has the most users/installations/implementations, etc.
In those debates (some would say full on arguments), various "reasons" are discussed on why this or that Pascal chose to implement or not implement a particular language feature.
What I realized after getting access to the full Pascal User's Group newletters, and reading other various texts by Wirth, Kenneth Bowles and others, was that the major subdivision in Pascal dialects came from Wirth himself.
http://www.moorecad.com/standardpascal/pug.html
Lets go into some of the evidence for that briefly. First, USCD Pascal came from the P2 compiler, which was a series of P-system implementations that Wirth's Zurich group produced labeled from P1 to P4, which were their idea of versions. This comes from both the newsletters and documents in the UCSD archives quoting Bowles.
Second, the matchup between what is in and not in the Pascals from UCSD and Borland corresponds well with what was left out of the feature set of the P-system compiler:
* Procedure/function parameters.
* Interprocedural gotos (goto must terminate in the same procedure/function).
* File handling other than "text".
* "mark" and "release" instead of "dispose".
* Curly bracket comments {}.
* The predeclared identifiers maxint, text, round, page, dispose, reset, rewrite, pack, unpack, and the functions they represent.
* Undiscriminated variant records.
* Output of boolean types.
* Output of reals in "fixed" format.
* Set constructors using subranges ('0'..'9').
And this is the function set for P4. P2 might have left off more Pascal features.
Wirth intended only that the P-system leave off features of Pascal that were not directly germane to accomplishing the bootstrap of the P-system to a compiler. Wirth says this himself in PUG letters. As well, Wirth several times mentions using the P-system to "bootstrap" to a full compiler. It was clear that he never intended for the system to form the basis of an interpreter only system (not saying he would have thought that good or bad, just that this was not his intent).
Reading through the PUG letters, it is also clear that there was a trend, in that most mainframe implementations of Pascal used the original Zurich CDC 6400 series compiler as the basis to create a new compiler for other machines, not the P-system implementation. As such, those compilers would never have been subsetted. Use of the P-system to create a Pascal system was more attractive for microprocessors.
This is not intended to "solve" the ISO vs. other dialect debates, but rather, these facts are germane to realizing why a split occurred, why it basically happened down small vs. large machine implementations, and why the different microprocessor implementations tended to leave out similar features of full Pascal.
--Samiam95124 05:31, 10 November 2005 (UTC)
PS. Chris, there was a comment by Wirth I found to the effect that "p-system didn't need a dispose" since it didn't do a significant amount of recycling, and was a bootstrapping article in any case.
The actual new protocal was: execute a mark, then any number of new's, then a release, which would release all new allocations since the mark. UCSD still had this protocol.
The relationship of Ander's compiler to Pascal is less straightforward. Anders clearly copied a lot of the UCSD features, but (from what sources I have found) Anders didn't use the P-system kit, but rather coded assembly from scratch. That would tend to make the link between UCSD and Borland by imitation, not by use of the same code.
--Samiam95124 20:07, 10 November 2005 (UTC)
I agree with your points about dispose and Anders. In PUG5 there is correspondence about the removal of DISPOSE in which Wirth says "it never really existed".
For the record, I totally disagree with your interpretation of events in this section. Wirth's thinking was simply progressing, with experience and hindsight, towards what eventually became Modula-2. i.e. no gotos of any sort whatsoever, no packing, no file operations in the language etc. However, I'll limit my edits to indisputable points of fact.
--Chris Burrows 00:45, 11 November 2005 (UTC)
I left your change alone, but note that "procedure and function parameters" is the official terminology for procedures and functions passed as parameters.
I don't really understand your point above. P-system was subsetted from full Pascal because Wirth was progressing towards Modula ? Come on.
--Samiam95124 02:08, 11 November 2005 (UTC)
I rewrote it, it was overly wordy for one thing. I'm not trying to construct the ultimate history of Pascal here, the intent is more to educate concerning the common question that arises here about why the Borland/Standard Pascal division exists, hopefully in a neutral fashion.
--Samiam95124 02:25, 11 November 2005 (UTC)
Chris, you are a smart guy, and know a lot about the subject, and I value your contributions. But you also fire off a few facts based on your recollections without checking them.
Now I have provided some amazing historical material online for you if you will just read it. What do the Pascal Users Group news letters say ?
First of all, UCSD Pascal was clearly branched from P2, the second version of the P-system from Zurich. This fact is found both within the newsletter and in online sources from Ken Bowles, and it is stated in the newsletters by Professor Bowles himself.
The P-system was modified extensively by professor Bowles certainly. Because he wanted to leave it as an interpreter, and have it be efficient and compact, he essentailly made it into what today would be called bytecode. That is, the operands and fields were optimized for bytes. However, the functionality was not substantially changed, other than the many extentions Bowles put in.
How about you read some of the backround material for this? I value your contributions -- backed by historical record. I seem to be one of the only people reading the material and contributing to this page with that, I would like some company. I certainly don't want to fight over every fact with someone who hasn't read it.
Sorry for the rant.
--Samiam95124 21:05, 11 November 2005 (UTC)
I *always* check facts before making changes and did look up the relevant articles in PUG. I would discuss anything that I didn't feel certain about, but then I don't usually get involved with such issues. The ETH Distribution is referred to as PASCAL-P. If you recall what I previously told you, I was responsible for distributing PASCAL-P for some time in this part of the world (Australia). p-System (which I also used extensively) describes the UCSD effort and and may even be a trademark of UCSD, Softech, Pecan etc. It describes the compiler, editor, assembler, filesystem etc. Only the compiler was based on PASCAL-P (Pascal-P is also acceptable). Why so defensive? I am your company - I am not fighting with you - just trying to help you get it 100% right.
--Chris Burrows 23:52, 11 November 2005 (UTC)
I was referring to your comment that UCSD p-system was not Zurich, which sounded like "there was no relationship". Sure, I see the fine point in spelling, I'll be sure to use the Pascal-P nomencature in the future.
Its probally the written nature of our correspondence, but some of your pronoucements come with scant references and sound like edicts delivered from on high ("it happened because I know it").
The way forward is the wikipedia way. Cite before you write.
Real programmers don't use Pascal
May or may not have belonged here. However, the main Pascal page is not a debating thread. The fact that the inclusion of the article is an opinion, and open to debate is reason enough. Also, it is not "criticism", its meant to be funny.
Finally, having a section "criticisim" seems to invite debate (ohh, lets put what I don't like about Pascal here). To keep this factual, it seems to me to be a place to list famous criticism from Pascal history, not today's anti Pascal rant. My 2 cents.
Am I making this page dry as dirt? Yep. Tell me that's a bad thing.
--Samiam95124 02:35, 4 November 2005 (UTC)
Since a lot of compilers borrow/base from/on each other, maybe it would nice to come to some (graphical/pic) pedigree ?
--Anon.
Absolutely. Are you volunteering to do the work? :-)
Why (or why not) standards compliance on the PC
About RFC1394's comments re: the standards status of PC compilers.
First, the reason I have started essentially "top posting" subjects that come up here is that many editors of the Pascal page are NOT reading the discusssions that pertain to their edits. Putting this material at the top hopefully will attract their attention.
To the subject at hand. First, and most importantly, there are lots of subjects that can generate endless wars on this page, including why or why not the standard, whether Borland should be considered "the" Pascal or not, etc. These controversial subjects should be discussed neutrally, or not at all on this page, for the simple reason that we don't want to get into edit wars on this page.
Now I rejected the change specifically for two other reasons. First, there is a long explantion on the difference between facillities on mainframes and PCs. It was acutally quite good, but it was not germane to the subject at hand, Pascal, and appeared to be entirely formed to support the editors conclusion, that standards are not necessary on the PC.
As to that point, the facillities that are or are not present on the PC have nothing to do with the standards status of Pascal compilers on the PC. There is nothing in original Pascal or the standard that was not capabile of being implemented on the PC. There was nothing in original Pascal or the standard that prevented the language extentions commonly provided on the PC.
As defacto proof of that, if one is needed, there were several ISO 7185 Pascal compilers available on the PC since its inception, and there exist several ISO 7185 Pascal compilers on the PC at present, including GPC, IP Pascal, Irie Pascal, DR Pascal, and perhaps others I don't know about. None of these compilers are particularly limited by their choice of language standard. GPC and IP, in particular, support full windowed graphics and other advanced I/O.
Formatting
First, I apologize for essentially top posting this subject, but apparently some users are having trouble finding current discussions.
Re: The anonymous person who apparently wants a revert war over formatting.
1. You are anonymous. Get a login. Making changes over again over again under an anonymous login has a name, its called "page vandalisim" and I can and will revert it when and if I find it.
2. I wrote the examples on this page. The page sat here for more than a year without anyone taking the time to write those examples, I deserve some RESPECT for the hard work I did on this page.
3. Adding blank lines after the begin and before the close of a block is an old and time honored means of increasing the readability of Pascal programs. See Henry Ledgard "Pascal With Style: Programming Proverbs".
4. Its a FORMATTING ISSUE, for Christ sake. Nobody agrees on formatting. Live and let live. Take a valium. Relax. Let others alone and stop trying to reshape the world in your image.
5. Jumping on the page again and again and changing it without comments (especially anonymously) is asking to be reverted. Get a login, and come discuss the issue here on the talk page. Everyone else does that. Get a login, and POST what you are doing and why here first.
In short, stop acting like a vandal and I'll stop reverting you. I have left the vast majority of the changes to this page stand, and you will find me very reasonable.
Thank you, end of rant--Samiam95124 00:04, 5 October 2005 (UTC)
Why I rejected certain formatting changes.
1. The change to:
program hello;
Instead of:
program hello(output);
ie., no header files was entirely Borland specific. Pascal requires "program hello(output);" or having the output file specifically declared. Its not even a necessary change to make it run on Borland, Borland just ignores these parameters.
2. Removing blank lines on begin-end pairs:
begin
writeln('hello, world')
end.
vs.
begin
writeln('Hello, world')
end.
Clearly indenting and marking blocks is good style not only in Pascal, but C as well, and has appeared in Pascal literature several times.
3. Extra semicolons:
begin
writeln('hello, world');
end.
Extra (dangling) semicolons are allowed at the end of statement-sequences, but this is hardly good style. In Pascal, the semicolon is a statement separator, its akin to saying "do a write, and then do this, and then do that". Adding the extra semicolon is like saying "do write, and then".
Other matters: indentation usually generates a good fight. Wirth seemed to use 2 characters, 4 characters seems to be borrowed from C, 8 characters (a tab) sometimes appears but everyone seems to agree its way to much. I think anything from 2 to 4 is fine.
--Samiam95124 20:54, 5 October 2005 (UTC)
Just discovered the discussion section! What a great idea! ;-)
Extra (dangling) semicolons: I am employed as a programmer and my company writes its software in Pascal (well, Delphi). Code in my life is always changing. If you don't leave in the dangling semicolins then when you come to develop the code further it doesn't compile. For practical purposes real working programmers will always use them. But it doesn't really matter does it so I'm quite happy without them. It's not as if it's really worth getting worked up over.
Indentation: "anything from 2 to 4 is fine". Agreed, but it's much more important to pick a number and stick to it. The examples as they are right now are inconsistent (they are mostly 4 but have some 3 and 5 thrown in for variety).
Blank lines on begin/end pairs leads to lots of white space which doesn't always improve readability. The great thing about modern code editors is that they highlight keywords. And when begin and end are highlighted the blocks which they delimit stand out. I feel this relieves the need to surround them in white space which does waste valuable screen real estate.
One thing that felt very irritating was your style of reverting wholesale and losing good points. I put in a good deal of effort highlighting keywords in bold. Because you didn't like another minor aspect of my change you reverted the whole lot and undid my bold! You also have a history of reverting and reintroducing spelling errors. Please take more care.
Scott/Samiam: you do a lot of good stuff here on this page but it's not your private fiefdom. A bit more humility and a bit less "I wrote those examples and they are mine...." bluster wouldn't hurt.
How about we at least agree on a single indentation style? I propose 2.
Misc
Could somebody fix the link to the GNU Pascal compiler please? --HJH
- Fixed on Sep 2, 2002 by Jan Hidders
October 9, 2002 - I think the list of criticisms should probably be removed as it seems out of place and is no longer current. -- Jim
- But it is of historical interest at least -- Error 03:40 8 Jul 2003 (UTC)
- For this reason I move the detailed point of criticism to this talk page. The article as a whole is not yet fully developed. It talks nothing about data types, syntax etc, so if so much space is dedicated to criticism it makes a very unbalanced first impression. If there is more stuff written on the language the following should be moved back. --Hirzel 11:01 8 Jul 2003 (UTC)
Agree, filled it out a bit on language description.--Samiam95124 00:07, 25 Jun 2005 (UTC)
The summary of Kernighan's criticism of early Pascal in that paper is as follows:
- Since the size of an array is part of its type, the programmer can't create procedures that deal with general arrays, without regard to their size. This is particularly a problem for string handling.
- The lack of static variables, initialization and a way to communicate non-hierarchically combine to destroy the ``locality of a program - variables require much more scope than they ought to.
- The one-pass nature of the language forces procedures and functions to be presented in an unnatural order; the enforced separation of various declarations scatters program components that logically belong together.
- The lack of separate compilation impedes the development of large programs and makes the use of libraries impossible.
- The order of logical expression evaluation cannot be controlled, which leads to convoluted code and extraneous variables.
- The 'case' statement is emasculated because there is no default clause.
- The standard I/O is defective. There is no sensible provision for dealing with files or program arguments as part of the standard language, and no extension mechanism.
- The language lacks most of the tools needed for assembling large programs, most notably file inclusion.
- There is no way to override the type system, most notably, no casting.
As mentioned above, the currently available compilers address most of these issues.
- Even if we accept that modern compilers extend the language to resolve the problems, his reasons are extremely dubious: either wrong or arbitrary. The sole valid arguments are the lack of separate compilation/modules (though units are a standard Pascal compiler feature, even if not part of standard Pascal) and the limited file access and complete lack of commandline-argument access (ditto). The only reason I mention it is that the main article and this page both take the assumption that all of the reasons are valid. Here's the list of the numbered reasons that aren't completely valid:
- 1. Conformant arrays are a part of the standard.
- 2. Static variables are a misfeature. There's usually a method that's more elegant and efficient to solve the problem.
- 3. This is actually a sloppy quirk in C, not a limitation in Pascal. Even C++, the successor to C, requires functions to be declared before they are used.
- 4. Technically true, but C only has a preprocessor that puts included files in the source. A Pascal programmer could do the same thing manually.
- 6. A "default clause" in a case statement is rarely needed, there are usually more elegant ways of acheiving the result. Besides, anyone who is defending something as awkward as the C switch syntax has no right to bash other languages' equivalents.
- 8. Correct, but that's the third time he mentioned it: see also 4 and 7. This is technically invalid since it's just upping the reason count.
- 9. Variant records and pointers are a way. Just because Pascal doesn't make it easy to shoot yourself in the foot doesn't mean that it's impossible.
[Scott A. Moore] For interest, here is my counterpoint to Kernighan:
For the points above:
1. This was Kernighans best point (and he says so, "this botch"...). Wirth had a point about "withholding the limits of an array from the compiler" J&W, but it carries theory over practicality. Alogol, Pascal predecessor, had variable arrays, and so did Wirth's own languages after Pascal, Modula and Oberon.
2. Absolutely disagree. Static variables, better known as globals, are in the language as much as they ought. The idea of a static placed in a function as a "pseudo local" would not be useful unless it were preinitalized, and preinitalizing variables in general takes code that ought to be visible to the programmer and hides it in the implementation. The C language must have two versions of statics, one the preinit copy, and one the actual variables, and copy one to the other, or let the user scribble over the preinit copy (which creates virtual memory copy on write and sharing issues).
3. Right, but wrongly blamed on one pass compilation. This is really part of 4 (separate compilation), and most modular compilers relax dec order.
4. Separate compilation. Absolutely C's biggest advantage. No argument.
5. Disagree. Having the user dictate the order of expression evaluation, even between operators that are otherwise associative, ties the hands of the optimizer. This is one of the worst features of C. It is true that it creates code difficulties with novices, for example "if (i < 10) and (a[i] = 2)" where the test for i is a valid index will fault because a[i] is executed regardless, is reformed as "if i < 10 then if a[i] = 2", etc.
6. No, having an "else" or "otherwise" addition to case makes the users OVERUSE the case statement by sticking many unrelated, or very sparse, cases into it that would be much better served by a string of "if" statements. Example:
case a of
50:... 102: ... else ...
end;
Does not acheive enough relationship between its cases to justify use of a case statement, which certainly implies to the compiler that it can optimize the case statement (with say, a tabled jump).
7. Absolutely correct. In fact, I believe I have traced most of Wirth's assumptions about file handling to the CDC 6400 series computer and the Scope OS that ran on it (see my site for more details). Scope didn't allow named files in its "local, active file" area that programs were forced to use, then the Scope command language was used to associate external, named files on the disk with those in the unnamed area. I believe that Wirth didn't like the idea of introducing named files into Pascal (since filenames were and are OS dependent), and so he essentially formalized Scope's methods into the language, but I believe it was a mistake.
8. This is really point 4 yet again. I now disagree that includes are the way to do that, but we have learned a lot about languages since C was created, so when Kernigan wrote the article, the comment was fair.
9. Abosolutely not. Casting at will has been a disaster for C, and now language designers are scrambling to try to fix it, with C# and Java.
See also Kernighan's "software tools in Pascal", where he clearly shows that he thought the "fix" for Pascal was to make it look like C :)
This article should include a "Hello, world!" example since most of the other programming language articles have one. —Frecklefoot 18:01, 8 Aug 2003 (UTC)
- There is one for Pascal at the Hello world program Wikipedia article.
- I added an Hello World example along with some syntax comments a couple days ago. Forgot to mention it here. Jim 21:14, 13 Aug 2003 (UTC)
Super Pascal and non-numeric lables
The article says that "Super Pascal was a variant which added non-numeric labels, a return statement and expressions as names of types."
While I am not familiar with Super Pascal, Pascal's labels can only be non-numeric and have always been that way. I sense a possible confusion with dialects of BASIC, which did introduce non-numeric labels at some point.
Origins of Pascal
Removed text:
in an effort to make structured programming easier for a compiler to process
is quite wrong. These interests of Wirth came out of the Pascal project in fact. I met him at the Symposium of Programming Methodology and Compiler Design which my then employer, the Australian Atomic Energy Commission, organised in Sydney the mid-70s. He was the keynote speaker. We'd attracted him because we were distributing Pacsal 2000, then probably the best Pascal compiler available, which ran on IBM 360/370 mainframes and was based on Ikeda's trunk compiler. My personal contribution to it was to write (or rather rewrite) the installation JCL and instructions.
As he told it then, he'd designed PASCAL (as we than called it) as a paper-only language, to be learned by his students for on-paper exercises before going on to real languages. If this seems bizarre, remember that in 1970 we are talking about an age where CRT terminals were almost unknown outside the computer rooms of major computer installations. Students input their programs on coding sheets, punched cards, OMR sheets, or perhaps by teletype or other printing terminals, and most often received their listings back as printed outputs.
Wirth was amazed when someone, I forget his name, a professor in Holland he was, said he'd written a Pascal compiler! (Could have been Dijkstra? He was deeply involved in Algol at the time -- Marco van de Voort) But the language and its concepts never looked back. We had t-shirts with the words "Fortran makes it easy to write bad programs" screen printed on them. Ah, memories!
I'll try to find the symposium proceedings, I think I still have them, to flesh this section out a little. Andrewa 00:48, 13 Jul 2004 (UTC)
- I thought I remembered reading that Wirth designed Pascal in part as a reaction against the bloatedness and creeping featuritis that he felt had infected ALGOL 68, and that Pascal was his own idea of what ALGOL 60 should have become. Does this ring any bells? -- Dominus 14:55, 12 Aug 2004 (UTC)
- For example, in Pascal and its Successors, Wirth says "Freed from the constraining influence of [the ALGOL committee's]] consensus, Wirth developped the language Pascal in Zurich. ... The programming language Pascal was designed in 1969 in the spirit of Algol 60 with a concisely defined syntax representing the paradigm of structured programming." -- Dominus 15:02, 12 Aug 2004 (UTC)
- When I first read about Pascal in Acta Informatica in 1970 (?), I was told it was nicknamed "the minority report to the Algol 68 committee". Don Baccus 70.59.134.42 01:49, 17 December 2005 (UTC)
- Is there any recorded source for this? "PASCAL - User Manual and Report" doesn't mention it, nor does ISO/IEC 7185. --Prosfilaes 02:09, 16 August 2005 (UTC)
- Are you referring to the article above? The quote, which can be found on the link the author provided, is from an article written by Wirth, it's harder to get closer to the horses mouth than this. Otherwise please indicate which point you were questioning, please. If it was concerning the quote about "Wirth was amazed...", yes, I agree that needs some citations. --Samiam95124 02:01, 17 August 2005 (UTC)
- I'm referring to the part about Pascal being designed as a paper-only language. --Prosfilaes 03:07, 17 August 2005 (UTC)
- Yes, it needs some citations.--Samiam95124 19:38, 17 August 2005 (UTC)
Pascal vs C
The article says, in part:
- Another major difference [between Pascal and C] is that Pascal is strongly typed. This means that all variables must be defined with a specific type before they can be used. Also, incompatible variable assignments are not allowed without an explicit typecast. This prevents common errors where variables are used incorrectly because the type is unknown. It also alleviates the need for Hungarian notation—the practice of prefixing variable names with type-identifying letters.
This is nonsense, for several reasons:
- "Is strongly typed" has no commonly agreed-upon meaning.
- Assuming the definition given above, both Pascal and C are "strongly typed" and so this is not "a major difference" between the two languages.
- In Pascal, incompatible variable assignments ar enot allowed at all, with or without "an explicit typecast"; Pascal has no explicit typecasting mechanism.
- Since type declarations are required in C as well as in Pascal, it is impossible to use a variable incorrectly "because the type is unknown", so these sorts of errors are not "common". The author of the passage may have been thinking of some other common error, such as casting data to the wrong type or dereferencing pointers incorrectly.
- The "need" for Hungarian notation is widely contested, but if there is such a need, it would appear to be just as valid in Pascal as in C.
I think this paragraph needs major alterations. In my view, the type system differences between Pascal and C have been greatly exaggerated. I know that many people disagree with me on this, so I don't want to alter the paragraph myself without getting some consensus first. But as it stands, the paragraph is not simply wrong, but absurdly wrong, and it must be changed. If I don't hear otherwise, I will remove it.
-- Dominus 14:53, 12 Aug 2004 (UTC)
I don't think it should be removed. Afaik C doesn't e.g. provide means to change an alias into a new type like type x = type integer; (or is that Borland ext?) Moreover C and C++ typesystems are different (and often confused), and so are K&R and Ansi C. (K&R pretty much has none).
However Pascal is indeed not 100% strong typed, even though a lot of people think so. E.g. Pascal has a lot of type equivalency between the numeral types, which is not strictly typed. (see e.g. M2), just like C. It also doesn't have a notational difference between a cast and a conversion, just like C ( (int) <something of float containing 1.0> returns 1, not the first bytes of the float value cast)
So some nuancing might be in order. (but considered dull probably)
-- Marco van de Voort
Not to start a holy war or anything, but here's the passage that got my dander up:
- Pascal allows passing parameters either by value or by reference. In C, parameters can be passed only by value, which is a serious flaw.
I would call the "serious flaw" designation subjective at best and ignorant at worst. C does too have call-by-reference! I prefer the C notation, in which the function call's syntax indicates that the argument is being passed by reference. I think it's perilous to be able to redefine a function/procedure argument's var-vs.-val later without requiring a reexamination of the callers. I also once wrote a semi-epic Genie Pascal program in which I was passing a value by reference down a fairly tall call tree. I dropped the var in the declaration of one of the higher functions, and it resulted in some perplexing, though non-fatal, behavior. I would've had a lot more trouble making the same mistake in C.
-- Ventura 23:12, 2004 Oct 14 (UTC)
C has no call by reference. It can pass a pointer by value though. That's different.
[Scott A. Moore] The use of &var notation in C to make variable references the same as value references may be a neat trick, but it has a price. The notation is indistingusable from the notation form a passed array. func(int *a) could be a as variable parameter, or it could be a as an array of ints. This created, for example, huge problems when making an automated header translator for C to Pascal, which is pretty much required to do any real interface work today, since all operating systems and packages are specified in terms of a C header.
This is yet another case where Pascals more specific notation pays off.
Turbo Pascal
The article says in part that Borland Turbo Pascal was only available on one platform. I believe this is incomplete. Up to Turbo Pascal version 3.0, you could also purchase it for Z80-based CP/M systems. The compiler was quite fast and pleasant to use, with a very good integrated editor. At the time you could take the same source code and compile it on either CP/M or an IBM PC running under MS DOS with almost no changes to the source file - if you used only the built-in Pascal functions for screen addressing, programs could be competely portable. The two versions used the same manual, with appendices explaining the PC and CP/M specific peculiarities. The PC version *could* manipulate slightly larger amounts of data in memory since it dedicated an 8086 segment to the variables (64K), whereas by necessity the Z80 version had to share all 64 K of RAM with the program code, data, and CP/M itself (and even the edit environment, though I believe it swapped out during program execution). An even earlier hobby-grade CP/M compiler for Pascal was JRT Pascal - which actually encouraged you to give away the program, though they retained copyright on the manuals. Sadly JRT Pascal was incredibly buggy and the company also managed to over-promise and under-deliver. --Wtshymanski 02:16, 15 Dec 2004 (UTC)
- I fixed this, it no longer says only one platform.--Samiam95124 00:26, 6 October 2005 (UTC)
True, besides the Z80, there also was a m68k Mac version. I can vaguely remember TP1/8086 having a unified 64k model, are you sure you aren't comparing later versions?
- I have version 1.0 with the Manual, and it supported 8086/PC and Z80/CP/M. This was the age when there were still more CP/M systems than PC systems. By the way, TPC 1.0 also claimed to be standards compliant, even though they clearly were not. They later dropped the claim.--Samiam95124 00:28, 6 October 2005 (UTC)
Edits
I have added this section because, being there exist widely differing interpretations of PascaL facts and history, I have stated my reasons for my edits to this page. It is not my intent to make this is political issue, but the page, as was written, read like a review written by a C programmer. I have not struck the entire "C to Pascal" comparison, even though it should actually be struck. Pascal is a language on its own, not a counterpoint to C. All in all, I would like to see this page more factual and more neutral, and hope all parties will agree to that.
samiam@moorecad.com:
1. Struck the reference to "C is a language for professionals". This implies that Pascal is not, and in any case was irrelevant to the subject at hand.
2. Struck the statement that "Pascal does not have differing lengths of integers and unsigned types". This is entirely untrue. Pascal just has a different notation for same, examples:
type n = 0..256
is unsigned byte. If a particular compiler chooses to interpret this as always a 32 bit integer, then that is a limitation of that compiler. A good compiler is free to limit the storage and signed status of the type.
3. I struck the entire diatribe at the end of the "C vs. Pascal" section containing judgment calls about Pascal being "flawed", about later improvements to Pascal making the language "as useful as C", etc. Certainly a section about later improvements to Pascal is in order, but its hardly a "C vs. Pascal" issue, nor C vs. Pascal warfare relevant to the information about Pascal. Just the facts please.
4. I have moved the C vs. Pascal section down. The purpose is to define "what is Pascal" first. Comparisons with other languages is certainly relevant, but not before the user is even informed about the subject itself.
5. In the "hello, world" example, I struck the note that "input, output are not required [in the header]. The text did not state "on some compilers" or other clause. Original Pascal certainly does require that "output" appear in the header.
6. From the "criticism" section, I struck the paragraph about "taking Pascal seriously". With my edits above, this whole article is more neutral, so a plea such as this is no longer necessary.
7. Added a reference to mine own page for standard Pascal.
(Scott A. Moore: I authored the above. Apologies for placing it on the wrong page, and thank you for correcting that. I understand Wikipedia much better now :-))
(This text was added to the article page by 192.18.42.10/192.18.42.11) — Stevie is the man! Talk | Contrib 04:00, 13 Mar 2005 (UTC)
I edited the examples so that they would conform with examples used in the authoratitive Pascal texts (e.g. anything written by Wirth, The Standard Pascal User Reference Manual by Doug Cooper, Software Tools in Pascal by Kernighan and Plauger etc. etc.) - i.e. removed null statements (superfluous semicolons). This change was reverted. I know full well that the examples are syntactically correct, and null statements 'do no harm' but as well as not conforming with other Pascal reference material, it could be confusing to a Pascal beginner.
I would find it acceptable if the person who reverted the changes added a paragraph or two explaining about the use of semicolons, null statements, the difference between statement separators, statement terminators, the dangling else problem etc? Otherwise, please remove the null statements. --Chris Burrows 26 Sep 2005
- Just change it back when you see it. This is part of a set of confused people who think that Pascal should look like C, and there is no reason for it. Semicolons are STATEMENT SEPARATORS,not STATEMENT TERMINATORS. Pascal is not C, and does not need to look like C.
- Should an article about Pascal get into style issues? Yes, I think that is proper. Pascal most certainly has a style, and I agree with your assertation that the original style of the author of Pascal should be paramount. In Niklaus Wirths "Users Manual and report" (With Ms. Jensen), he uses an extra, dangling semicolon perhaps 3-5 times out of all the examples in the book. The most common appearance of dangling semicolons is the programmers equivalent of "uhhhh", that is the programmer expected that more might be written there soon. A good example would be a case list that gets frequent additions.
- I have seen and heard people who have the idea that semicolons should ALWAYS be added at the end of a statement, but in every case of that I have seen the reason is because they were also frequent users of the C langauge, and wanted the languages to "match".
- By the way young man :-) The book "Software Tools" by K&P is a notorious ANTI-PASCAL diatribe that basically avocates adding useless syntax elements like extra parenthesis and semicolons, and misusing functions as procedures in an effort to make Pascal look more like C, so I find it funny that you mention this book in conjunction with a style complaint about Pascal code :-)
--Samiam95124 21:03, 26 September 2005 (UTC)
- Unlike previous discussions we have been involved in, I'm pleased that we are able to agree on something :-). I hadn't read the Software Tools book since 1982 and was surprised myself to see that Kernighan with his C background hadn't fallen into the semicolon trap. I'll have to read it again as I was unaware of any anti-Pascal bias in it. It sure was a lot better than the ghastly RATFOR version.
Pascal vs C
[Scott A. Moore] I propose we strike or change this section. The Wikipedia entry on C does not compare itself to Pascal, nor do we include comparisions to other languages. It became traditional somewhere down the line for C users and Pascal users to fight over their langauges, probally because these were two competing languages during the Microcomputer revolution.
As I said above, Pascal is not a counterpoint to C, it is a language. The section on C would be better as "differences with other languages" or somesuch, and hardly needs to go point by point by point of the exact differences with C.
I propose that history has a bigger view than to be about perpetuation of a petty user fight. Comments ?
2005/05/25 I have left the above comment up for some time. I will execute the proposed change.
[Marco van de Voort] Scott: kill it off. I also would, in general, like to see more history move to a/the "historic" section, and see the general text of the article more about the present... or at least the last decade.
OTOH the stigma that stick to pascal still haunt us today. So partially the C vs Pascal discussion is still alive.
So I left the comment about striking the Pascal vs. C up for some time, and it was restored without even a comment as to why. So clearly whoever restored that does not want to talk rationally about the matter.
I'm not going to use this page to fight over Pascal, so I am not going to get into a delete war. Whoever WANTS that C passage clearly is a Pascal detractor, which is the WRONG kind of person to edit the Pascal page (somewhat like putting Bolton as diplomat to the UN). The C page does not talk about Pascal, or discuss why Pascal is better. PASCAL IS NOT A COUNTERPOINT TO C. Its a language. --Samiam95124 20:24, 2 Jun 2005 (UTC)
- I have no objection to comparisons between Pascal and C. If someone (Samiam95124?) doesn't like the way they're written, they should be edited for NPOV. Having a rebuttal isn't the way encyclopedia entries should work. The informal self-reference ("As a Pascal promoter and compiler maker, I will state the Pascal point of view.") belongs on a talk page, not in an article. Let's edit what's there and make it NPOV instead of writing a rebuttal section. Gary D Robson 21:11, 2 Jun 2005 (UTC)
I don't know what NPOV is, but sure, lets settle on a format. I have two primary objections to the section on Pascal and C, which I would appreciate if you could address.
First, as said, the entry on the C language does not compare itself to Pascal. Why not Pascal vs. Snobol ? Lisp ? The entire idea of listing Pascal vs. Language X seems to me to invite languages wars here. If the idea was to point out what is not good about Pascal, the C language page has a section on "problems with C", and that certainly looks appropriate.
Second, that section (Pascal and C) certainly appears written by a C promoter/ ethusiast. The several mentions to "lack" on Pascals part indicate a bias to me. Lots of languages don't have (or need) preprocessing, pointers with wild abandon, etc. Yet I don't think that these languages are considered "lacking".
It seems to me that Wikipedia articles in general, and language articles in specific, should be left to people that like and study the subject. Otherwise, it becomes an invitation to Wiki Wars. Why should I not then go to the C language page and post about how bad that language is ?
So having got that off my chest, I will list my preferences in order.
A. Delete the "Pascal and C" section, or change it to "Problems with Pascal". I am not trying to suppress opinions about what is not right with Pascal, just cast it in other terms than "Pascal is flawed because it is not C".
B. Tone it down. Pascal is a problem because it does not have a preprocessor ? Come on. Most languages don't have preprocessors. Pascal has constant declarations and type declarations, both of which the C preprocessor was designed to supply. That leaves Macros, which have virtually everybody I know, including Stroustrup, disgusted with the lousy code that gets written under C.
Thanks for the attention.--Samiam95124 21:30, 2 Jun 2005 (UTC)
I'll take a guess you mean Neutral Point Of View. Here here, that exactly expresses my thinking. The more neutral, the better (and thats what I have strived for in past edits here).--Samiam95124 21:32, 2 Jun 2005 (UTC)
- Yes, that's what I meant. I think the section helps. Let's face it, more programmers know C than Pascal, and this gives people something to compare the language to. I've taken a first cut at making the section more of an informative comparison and less of a language-bashing excercise. Maybe we could add some syntactical differences to the list and make it really useful? You'd probably be better for that than I. I haven't used Pascal in five years, although I coded extensively in UCSD Pascal and Delphi. Someone more current in both languages should work on the comparison list. Gary D Robson 21:38, 2 Jun 2005 (UTC)
All right, I'll take your first point, and I'll go through the new version of the section here.
- "C has bitwise operations....." There is a misconception that Pascal sets are about bit manipulation. Actually, sets are horrible for bit manipulation, for a lot of reasons. First, when doing bit assembly/disassembly, you generally want to shift bit fields around, with shift left and right. Sets aren't designed to do that, they don't have any concept that you might want to take sequential bits together, or move them to other parts of the word, etc. Pascal users manipulate bits the same way that C users do, which is why bit shift operators are a common extention to pascal. I didn't include them in my compiler, because the compiler already does a shift when you do a * or DIV. "and" and "or" is another matter (you can do it in standard Pascal, but its hard and not efficient). Finally, the major reason you would want to shift bits is to pack multiple bits or other short operands into an integer, which Pascal does for you automatically via the "packed" keyword on a compiler that knows how to do that. So for example:
a = packed record
bit1: boolean; bit2: boolean;
..
end;
On a compiler that knows how to pack would allow bit fiddling without the need for shifts or "and"s.
(Samian: problem with that is that what if I want to set the bits that I have in an array of integer using that record? IMHO that makes the record way useless, and that records are bitpacked is not guaranteed Marcov)
- Bit fiddling an integer is clearly the ___domain of boolean operators on integers. Its true that wasn't in the original language, but most implementations add it. Also, it actually IS possible to do booleans on each bit in an integer in ISO 7185 Pascal, its just inconvient and slow.
- For records, the case is clear. Original Pascal included packed, and Wirth himself gives an example of record fields critically packed in a word (of the CDC 6000). So an implementation issue it certainly is, but a new issue it is not, it goes back to day one.--Samiam95124 00:52, 6 October 2005 (UTC)
- "C allows much greater freedom with pointers" starts ok, but wanders off. C has "malloc" and "calloc", Pascal has "new", and new is built into the language, not a library add on, so by some measures Pascals pointer methods are actually more flexible, because "new" knows what is being allocated (and hence can handle tag field allocations on variant records, for example). I think I disagree with "C is more concise for low level programming", since, as I handle a lot of low level programming in ISO 7185 Pascal myself, and its simply a matter of declaring a fixed object in memory via an external file vs. placing a magic number in the file, which is bad practice even in C. In general, I guess this paragraph is factual, but it makes it sound as if Pascal is braindamaged instead of simply having a different method of doing that same job.
(Agree, only lowlevel arguments pro C that I can imagine are things that help nearly non-optimizing compilers. Things like the combining of operators, assignments in expression and defining variables in scope. Moreover it is generally easier to optimize Pascal, less rules Marcov)
- also possible (to optimize Pascal) because Pascal garantees no aliases to common variables (that there exist no held pointers to variables), which makes it possible or impossible to determine variable lifetimes. Pascal does have VAR aliasing, and in both languages improvement in the code can be done by analisys, but in Pascal the job is simplier.--Samiam95124 00:52, 6 October 2005 (UTC)
- "Pascal lacks preprocessing" Again this appears entirely irrelivant. There is no need for one, so there is no "lack". In any case, it isn't even true. There are lots of preprocessors available for Pascal. Its a separate program, just as it used to be for C (it got integrated with the C compiler because preprocessors are notorious for giving bad error messages).
(Would become that Pascal has no standarised preprocessing then. While true, the need for heavy (and thus in-need-of-standarisation) preprocessing is mostly needed to workaround the minimal C language definition, so the requirement is C centric, and doesn't transpose to other languages)
- "Pascal lacks continue and break operators" Pascal also lacks brackets instead of begin..end, /* */ comments, etc. "lack" is the wrong word. Wirth specifically disincluded those statements, for good reason.
(most add it as extension btw, which indicates that it might indeed be at least a wanted feature. Marcov )
- A compiler maker may well have a responsibility to refuse to add "popular" constructs to the language. No one is in a better position to determine what will or will not affect code efficiency that the compiler writer, and users will assert the presence of such features as "proof" that such constructs are not bad. Wirth was in a rare position to shape the language in terms of what was efficient to compile to final code, vs. what was a needed feature in the language.
- "Pascal permits nested functions" actually so does C, its in the C99 definition :-) Seriously, this brings up the point, are we comparing old Pascal, old C, or some other mix ?--Samiam95124 00:27, 3 Jun 2005 (UTC)
Ok, so I'll be helpfull. I program about %50/%50 C and Pascal these days, so here is my version of your comparision:
- C features short syntax elements with special characters, for example "{" instead of "begin", "&" instead of "var", etc.
- C is oriented towards compact or very compact syntax. Functions are declared without a keyword in C, but in Pascal, "function" is required. (same as first Marcov)
- C has many special operators, for example "a *= b" instead of Pascal's "a := a*b". C has bit shifts (<<, >>) bitwise and and or, plus many other special operators such as ?:.
- C allows assignment anywhere in an expression, including multiple assignment within an expression. In Pascal, assignment is a statement.
- C allows the creation of a pointer to any program object, global variables, locals, etc. In C, pointers and arrays are considered equivalent.
- In C, boolean types are the same as integers.
- C allows "early out" break and continue operators.
Notice that the above is NPOV (your term). I didn't "ding" C for having wild pointers. C lets you do more with pointers. Thats C. Pascal isn't C.
Left out, on purpose were:
"C bitwise vs. sets". Sorry, its just misleading. "C has more operators" makes more sense.
"Pascal allows passing ... by value or by reference" C does too, it just uses a different method.
"Pascal provides subrange types" Ok I guess, but dosen't (to me) make sense all on its own. Pascal has a lot of typing restrictions, thats only one of them. Others would be, typed indexes, discriminated variants instead of unions, etc. Do we list them all ?
"Pascal lacks preprocessing". I think I beat that into the ground.
"C lacks typesafe enumerated types" Well, it actually has those and has since ANSI C. It still isn't typesafe, but none of C is.
"Pascal permits nested functions" So does C, since C99.
You know, I actually use C a lot and like it in many situations. Its this idea that all languages we like have to be amagamated into one giant superlanguage that is suspect. Pascal shouldn't look like C, and C shouldn't look like Pascal.
Cheers!--Samiam95124 00:27, 3 Jun 2005 (UTC)
I would like to make one last pitch for the elimination of the Pascal vs C section. Looking around in Wikipedia, NO OTHER language has this comparision to C. Look at Basic, ADA, algol, lisp, Fortran, even Java (which came from C!). None have this apparent need to be compared to C. I invite you to look at these, and any other language entries in Wikipedia, and explain why Pascal needs to have it.
Further, it is traditional for C and Pascal users to fight. The reason why is that the languages arrived at roughly the same time, and vied for the status of most popular general purpose language of the Microcomputer age. Also, most programmers learned both at one time or another. I would argue that there is no such thing as a really neutral comparision of these languages.
The right answer for this article to be NPOV is to have it not make this unfortunate comparision. Then it is truly neutral. Otherwise, whatever form you have this comparision in, it invites conflict.
--Samiam95124 04:18, 3 Jun 2005 (UTC)
- Okay, I think you've made your point. How about if we remove the Pascal vs. C section from here, and encourage anyone who wants to put in the effort to create a new article comparing the languages? Then both the Pascal article and the C article can link there. Gary D Robson 13:19, 3 Jun 2005 (UTC)
I'll write the first draft of the new article, probally over the weekend. Of course, its going to look something like what I outlined above, but then others will be free to edit it.
Wow, do you know how may pages we can create comparing languages ? Isn't it the square of their number or something like that ? :-)--Samiam95124 18:40, 3 Jun 2005 (UTC)
I have added a page called Pascal and C (the same title as the section under Pascal). For a first pass, I think it came out fairly well. However, I invite spelling corrections and edits. When (if ?) you are satisfied with its contents, we can make the change to strike the section from this article, and link that article.
You are on your own for C vs. Snobol comparisions! :-)--192.18.43.10 02:04, 4 Jun 2005 (UTC)
Saw a couple references to cleanup of the Pascal and C page, but no changes noted, so I have gone ahead with modifing this page to point to that, and remove the Pascal and C article from this page. I will personally pass on modifying the C page to also point to that. I don't really see myself arguing with the C zealots for why they need such a link on their page.--Samiam95124 22:02, 13 Jun 2005 (UTC)
Made some small notes in parentheses. In general I agree with Scott. Some points:
- The conciseness of C is true, but it is often implied that this translates to the actual code, which is wrong. Moreover readability suffers and it doesn't really safe time (the limiting factor is always thinking not typing)
- The lowlevel arguments make only sense with non-optimising compilers. Pascal is moreover easier to optimise. The Turbo Pascal compiler gave Pascal a bad name with regard to code generation quality, but that is a bit incorrect:
- Pascal can (and often is) be highly optimised. To at least the degree C is (actually digested programs don't differ that much between C and Pascal)
- The comparisons were unfair. Dominant 16-bit TP with its decade old concepts and technology was typically compared to the emerging 32-bit C compilers.
- this includes the perceived speed of combined operators, locality of variable declaration and (to a lesser degree) in expression assignment.
- The by reference, by var argument is IMHO important too for this part. The C style passing by ref (just a pointer) has some consequences for optimization (in terms of aliasing iirc). IIRC later standards improved on this, which brings us back to the question what versions are we actually comparing? E.g. the extended Pascal standard (or a delphi) is older than C99, so comparing ancient pascal with C99 is a bit unfair.
- The pointer arithmic of C is a lot less free if you strictly adhere to standards. Don't confuse what is possible in an implementation to what is allowed, since you don't do that for Pascal either.
Since we are talking about an unbiassed comparison, I have a small point maybe worth nothing:
- In general Pascal compilers have a lot better quality of error messages than C. This probably due to the simpler language, and recursive descent use. (yacc/lex cs generated parsers often have horrible quality errormessages).
- This is a good question, and after having designed a C compiler back in 2003, I found the answer to this issue. The problem is that the C language does not provide enough information to determine what exact error is causing the problem. For example:
stuff x;
- Is a common type declaration in C, with "stuff" being a type. Unfortunately, if stuff was misspelled, either in this invocation or the original declaration (or the declaration is missing), you simply don't know enough about it to deliver a meaningful error message. Contrast that with:
var x: stuff;
- And it is clear what "stuff" was intended to be, a type identifier.--Samiam95124 00:52, 6 October 2005 (UTC)
- Alrighty, I added the Pascal and C page to the C language page. Everyone duck ! Seriously, it seems to be well received (or perhaps ignored :)--Samiam95124 22:58, 30 August 2005 (UTC)
Edits
I moved the Turbo Pascal specific information to the Turbo Pascal section. Note that nothing was eliminated, just moved to a more appropriate section.--Samiam95124 23:20, 24 Jun 2005 (UTC)
Working on changing the "overview" section into a true overview of the language, so changed the section to "language".--Samiam95124 00:07, 25 Jun 2005 (UTC)
Borland specific features
Please note, this page discusses general Pascal. I realize that many editors here are of the point of view that one or more of the Borland series of Pascal languages are equivalent to Pascal. However, the Borland Pascals are well represented in various pages on Turbo, Borland, and Delphi version pages of their own.
There are many other Pascal implementations besides Borland. Even if Borland were to be considered the "official" Pascal, which version would you choose? There are at least three (Turbo, Borland and Delphi, and perhaps even Windows and non-windows). Finally, there is the original Pascal which Niklaus Wirth defined.
I don't have a problem with mention of one particular Pascal's features or extentions. I propose the following simple rules for that:
1. Mark extended features either as general, or as being a feature of a specific implementation.
- "Strings are an extention in most Pascal compilers"
- "Borland Pascal includes dynamic strings"
2. Keep Pascal extention discussions short. Extensive discussions of extended features on the the page provided for that particular Pascal implementation.
Thank you. --Samiam95124 15:06, 6 September 2005 (UTC)
Category
Samiam95124, I don't understand why you keep deleting the Pascal category from this article. Pascal certainly merits a category. Mirror Vax 11:57, 16 December 2005 (UTC)
Thats not the issue. You did a massive delete on all other catagories:
Category:Algol programming language family
Category:Educational programming languages
Category:Imperative programming languages
Category:Procedural programming languages
Category:Statically-typed programming languages
Category:Structured programming languages
Category:Pascal dialects
Explain why, for each of these catagories, why Pascal does not belong to them. They in fact, all appear to apply to Pascal.
--Samiam95124 21:58, 16 December 2005 (UTC)
So apparently you were not aware that you were deleting all of these other catagories when you were adding the new "pascal" catagory.
If you had POSTED something here and started a dialog to that effect, we could have told you this long ago. Instead, you insisted on coming in here and deleting parts of the page, over and over again without leaving any comment more informative than "catagory". You also did this right after someone went on a war to vandalize the page, which you would have noticed if you checked. Then you went from total silence and repeatedly deleting sections of the document to yelling at everyone who was trying to figgure out what the hell you were attempting to do.
Nobody's out to get you here. Sit down, settle down and talk to us (civily) from now on, we are not that unreasonable.
--Samiam95124 22:10, 16 December 2005 (UTC)
- I have already explained this to you (on your talk page). The Pascal category is a member of those categories, hence this article is too. You deleted the main category, the recently created Pascal language category. That is what I object to most strongly. If you want to put the article into redundant categories, then I won't revert that - even though it's wrong.
- I have categorized hundreds of articles with nary a complaint. I don't understand why the editors of this article are so...different. Mirror Vax 22:16, 16 December 2005 (UTC)
You made a mistake several times, you aren't catching that fact, I am tired of you. You will get reverted when you do that. This time, next time, any time. Bye.
--Samiam95124 01:12, 17 December 2005 (UTC)
- Category:Pascal is included in all the old categories on the page, thus as per standard practice, Pascal is removed from the old categories and put only in Category:Pascal.--Prosfilaes 04:01, 17 December 2005 (UTC)
- Ok, fine. First of all, not all of these catagories appear on the new "pascal" page. Second of all, it does not strike me as all that convienent. I put a lot of work into making sure all of the different Pascal dialects are collected onto the Pascal dialect page, now that is buried 2 levels deep in another page. Is Wikipedia that hard up for space that a few lines matter ?
- Further, if there is a style issue that affects Wikipedia overall, then surely you all are ready to reference the Wikipedia style document or discussion that deals with it.
- Finally, I would appreciate your looking at the catagories individually, telling if they appear on the new "pascal" sheet, why they are not, and why they shouldn't appear on this page, which after all is the flag sheet for Pascal.
- It certainly is an improvement to talk about this. I am reasonable, but look at the way this change was done. It was simply edited several times, without any reasonable comment, and no prior discussion. When it was reverted several times, the editor started yelling at and insulting everyone who reverted the change, still without discussing why the change was required. Now we are talking about it, but only with the change STILL being made again and again without prior discussion.
- Wikipedia is a concensus, not an insergency.
--Samiam95124 18:16, 17 December 2005 (UTC)
What is wrong with each of these catagories? They all look valid to me.
Category:Algol programming language family
Category:Educational programming languages
Category:Imperative programming languages
Category:Procedural programming languages
Category:Statically-typed programming languages
Category:Structured programming languages
Category:Pascal dialects
One of them, Pascal dialects, I have put a lot of work into fixing up so that it shows as a universal directory of Pascal implementations. So, yes, I have issues with simply deleting it.
--Samiam95124 08:06, 17 December 2005 (UTC)
A quick tour of various programming languages here, C, Java, LISP, shows that they still have various catagories at the bottom. So Pascal is (apparently) the only language here being held to this new "one catagory" concept.
Compiler History
This was moved from the unrelated topic above.
- So what's the protocol for adding compiler history to this article? For instance, the University of Illinois's PDP-11 Pascal compiler is mentioned, but not the 90% rewritten ESI Pascal compiler that was released with commercial support in 1975. This was the first commercially-supported Pascal compiler to be released. And that begat Oregon Software, a compiler technology company whose Pascal compiler was widely used (google "OMSI Pascal", "Oregon Pascal"). Oregon Software's compiler technology was the basis for DEC's RSX-11 Pascal and MicroPower Pascal (which included a real-time kernel for embedded applications). Back in the day when PDP-11's were the most common "personal computer" found in labs, universities, and industry, Oregon Software and its Pascal compiler technolgy was widely known. Oregon Software supported Pascal (and eventually C/C++) on the VAX, Motorola 68000, National Semicondictor 32000, SPARC, and lesser-known architectures. I'm writing about my own company, here, not sure I should add such information to an article such as this myself. Don Baccus 70.59.134.42 01:59, 17 December 2005 (UTC)
Compiler history is most welcome here. Many compilers have a short entry on this page. If your notes are extensive, may I also suggest you create a full page on the implementation ("OMSI Pascal", "Oregon Pascal", or both). Then, please link to that on the "Pascal Dialects" page.