Talk:Pascal (programming language)/Archive 1
 | This is an archive of past discussions about Pascal (programming language). Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
| Archive 1 | Archive 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 labels
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.
Should we add a common commands section?
I had an idea that might prove worthy for wikpedia on not just pascal but other progamming languages as well. We could have a section that has some of the most common functions and what they do.
I would've already implented this idea but I wanted to make sure It wasn't going in the wrong place or wasn't usefull.
--Chosen1 1/27/05 1:58pm central
New Compiler
Dev-Pascal is a rather powerful IDE based compiler for pascal, made by bloodshed, the same people that made the Dev-C++ IDE environment, which in my opinion has almost as mcuh power as microsoft studio in a much simplier package.
Dev-Pascal doesn't make a compiler. They just have an IDE over two existing, already mentioned compilers; FPC and GPC
Requested move
Pascal programming language → Pascal (programming language) – Conformance with WP naming conventions LotLE×talk
| This discussion has been closed. Please do not modify it. |
|---|
| The following discussion has been closed. Please do not modify it. |
The result of the debate was move as outlined. -- tariqabjotu 02:43, 7 September 2006 (UTC)
Some editors have proposed a general rename of articles named with the pattern "FOO programming language" to the pattern "FOO (programming language)". Please note that this poll only is applicable to those programming languages whose names alone would introduce ambiguity. For example, programming languages such as Java and C , whose names alone are ambiguous, would be at Java (programming language) and C (programming language), respectively. Unique names such as Fortran and COBOL, should remain at their respective simple names. For instructions on how to add a poll participation request to additional applicable article talk pages, please see: Wikipedia talk:WikiProject Programming languages#Poll procedure Please add "* Support" or "* Oppose" followed by an optional brief explanation, then sign your opinion with ~~~~ Voting
DiscussionResponse to DNewhall's commentIn order to reduce clutter in the voting section, i've deicded to respond to DNewhall's vote here. If you're afraid of the amount of work it would take to move the articles, I can move most of them and i'm sure there are other editors willing to take up the task. Also, most books about programming languages simply have the title or common name of the programming language as the title of the book -- the Wrox series uses "Professional PHP" or "professional Java", not "professional PHP programming language" or "professional Java programming langauge". Many of the books I have also have the sorting information as "Computers -- Programming languages -- X," where X is the programming language. atanamir 23:36, 1 September 2006 (UTC)
Repsonse to Deco's commentImagine if you have a set of objects which all fall under the same category -- let's say they're all different types of Widgets. The types are Alboo, Kabloo, Hello, Wawoob, Baboon, Choogoo, Chimpanzee, etc. Because some will cause ambiguity -- Hello, Baboon, and Chimpanzee -- they need to be disambiguated. However, since the common name (in this case, the real name) is "Hello," "Baboon," and "Chimpanzee," wikipedia has an established precedent of using parentheses. Thus, the unique widgets, Alboo, Kabloo, Wawoob, Coogoo, can have articles simply at the name itself; but the ambiguous names should have articles at Hello (widget), Baboon (widget), and Chimpanzee (widget). Thus, the article titles will be uniform in that they are all "at" the name itself, but with a disambiguator on several of them. This is easier than making all of the articles at Alboo widget, Kabloo widget, Hello widget, etc. Also, it allows for the pipe trick, so links can easily be made with [[Hello (widget)|]] --> Hello. atanamir 23:54, 1 September 2006 (UTC)
Simpler disambiguationEven if we add the parentheses, the guideline at Wikipedia:Disambiguation#Specific topic makes sense to me:
In this case, we could have the simpler and more widely applicable "(computing)" instead of the long "(programming language)". --TuukkaH 10:04, 2 September 2006 (UTC)
Pages like C programming language, criticismTo meet the new standard, the pages should be moved to something like Criticism of C (programming language), right? examples are Georgia (U.S. State) and Politics of Georgia (U.S. state). atanamir 02:42, 5 September 2006 (UTC)
|
pointers article
Not related to this page, but could sb have a look at [2] ? It seems it is Borland centric. (most notably can inc/dec be used on ptrs in std pascal?) But please keep a note on Borland differences.
I looked at it, it seems ok. Perhaps it got fixed?
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)
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.
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)
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)
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.
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)
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.
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.
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.
Davidheffernan 22:02, 16 December 2005 (UTC)
David, see my note in Edits for the reasoning behind removing superfluous semicolons in published examples (as opposed to personal code, or code conforming to company standards etc.) I agree with all of your other points and second using 2 blanks for indentation.
Chris Burrows 23:22, 18 December 2005 (UTC)
- I am sorry for not reading this sooner... My fault. I have changed the (output) back.. jsimlo 14:24, 30 August 2006 (UTC)
- Extra (dangling) semicolons: The article says semicolons separate statements. But then, in the very next example, no semicolon occur after the writeln statement to separate it from the end statement. So, either point out, that there is no need to use semicolon before end statement, or use the semicolon in the example. Otherwise it is just confusing. jsimlo 14:24, 30 August 2006 (UTC)
- end is not a statement. It is the keyword that terminates a block statement, not a statement in itself. Henning Makholm 16:38, 30 August 2006 (UTC)
- Neither begin nor end are statements. They are keywords that always come in a pair in a begin-end block (which itself is called a compound statement). -- RTC 21:20, 30 August 2006 (UTC)
false stuff
removed some false stuff --Windymager 18:57, 11 February 2007 (UTC)
a number of concepts were imported from C
This sentence in the TP description is extremely far sought, and IMHO simply false:
- function pointers are not brought from C, procedure variables exist in Pascal. BP simplified them to be _internally_ be a single pointer, but that was a performance tweak, and much older than the TP versions that had to interface to the winapi. Samian explains in the first comment on this page that this traces back all the way to P2
- The prodedure variables in TP are quite a different beast from the procedural parameters in J&W Pascal (which the predecessors to TP never supported). In J&W Pascal, a procedural parameter can refer to a nested procedure, but is a second-class citizen - the only thing you can do with it is call it or pass it onwards as a parameter; in particular you cannot store it. Conversely, the procedure variables in TP are first-class data, but could not refer to nested procedures. (I think Delphi later changed that by some kind of implicit thunking, but this restriction certainly existed in TP). These features are exactly (no more, no less) what is needed if one wants to participate natively in an API that uses C function pointers. Henning Makholm 10:26, 16 April 2006 (UTC)
- Still that is IMHO revisionism, since this decision was made more than 10 years before C api's made an appearance. Compiler simplicity in the (assembler!) TP range is more likely to be the reason. What does UCSD do? 88.159.73.216 11:19, 18 December 2006 (UTC)
- Which "decision" and which particular 10 years do you refer to? Note that Turbo Pascal did not have zero-terminated strings or those other features from its start; before the first version supporting the win16 API, the only strings were fixed-size length-byte strings, and earlier TP versions had no concept of subroutines-as-values at all. Henning Makholm 19:32, 18 December 2006 (UTC)
- The simplification of procedure variables to single pointers (iow removing support for transparant passing of both global and nested procedures). I don't oppose that TP does this, just that C or Winapi is not the reason but either UCSD ancestry or avoidance of compiler complexity. 89.220.1.49 09:53, 16 March 2007 (UTC)
- The "zero terminated" string support is also a bit far fetched. To my knowledge the only language extension is that ^char can be overindexed as an array.
- Why far fetched?
- Chris Burrows 07:16, 16 April 2006 (UTC)
- It suggests more than there is
88.159.73.216 11:19, 18 December 2006 (UTC)
- afaik pointer arithmetic is not possible in the Borland Pascal versions, without explicty casting of pointers to integers. Incrementing pointers with INC() only started in Delphi with the linear address model.
- pointer arithmetic is not possible in original (Jensen and Wirth) Pascal in any way, shape or form.
- Chris Burrows 07:16, 16 April 2006 (UTC)
- In particular TP, allowed one to use PChar variables in inc/dec/prec/succ. That is a major conceptual departure from the rigid pointers in J&W Pascal. Henning Makholm 10:26, 16 April 2006 (UTC)
- Again this suggests way more than there is, based on a few corner cases. Relaxed pointers a bit here and there: yes. Pointer arithmetic ? No, because then people expect behaviour going as far as C.
88.159.73.216 11:19, 18 December 2006 (UTC)
- "unsafe" typecasts can mean pretty much anything. Afaik TP has the same rules as pascal clasically. Casting only possible if sizes are the same. I don't have the Pascal standard available, but I do have the M2 "Programming In M2 3rd e.d.", which seems to allow typename to be used as "type transfer function that generate no additional instructions because the datarepresentation is the same", iow pure casts.
- Wrong. Typecasts were not possible in original (Jensen and Wirth) Pascal, except for via the use of type-transfer functions e.g. ORD and CHR. What Modula-2 does is irrelevant to this discussion.
- Chris Burrows 07:16, 16 April 2006 (UTC)
It does since "import van C" is one of the things I object against. If it could come from a different lang (and M2 is not that far fetched).... 88.159.87.12 09:49, 23 July 2006 (UTC)
- "Usafe" typecast means that one can cast from integers to pointers (and vice versa) without restriction - another feature needed to speak the Win16 API which very often passes pointers in 'long int' fields and parameters. Neither direction is possible in J&W Pascal. Henning Makholm 10:26, 16 April 2006 (UTC)
- Again this was already changed aeons before the win16 api emerged.
88.159.73.216 11:19, 18 December 2006 (UTC)
Anyway, except the extremely limited syntax simplification for pchar, there is nothing C related here.
- I disagree.
- Chris Burrows 07:16, 16 April 2006 (UTC)
intended to teach students structured programming
How strong is the support for that statement? His books are not about programming: they are about programming languages. He wrote a new edition of his book on compiler design for each language he published: the oberon edition is here: [3]
Wirth says that "Confronted with the duty to teach programming, [I designed] Pascal", [4] but slightly about that he says "Programming languages were one of the first topics that established computing science as a discipline with its own identity.", supporting the idea that his idea of teaching computer science was to teach language design.
Arguably, the article should read "Initially, Pascal was a language intended to teach students compiler design"
"Pascal was originally intended primarily as a teaching language" is a quotation from Kernighan, [5], he doesn't give any source for it either. The Wirth source he does give [6] does not contain that thought.
I thought that it had been clearly stated by Wirth that Pascal was not a language intended to teach programing, but I don't have a source: does anyone else have a direct quotation?
(Dijkstra was interested in Programming: a comment on the distinction is included here: [7]. If you read Dijkstra and Wirth you can see that every thing Dijkstra wrote different from everything that Wirth wrote) (david)150.101.166.15 10:48, 22 June 2007 (UTC)
Unlikely Claim
I have requested a citation on the statement made in the first paragraph "It was made popular by Mike Slater of the Blackpool Sixth Form College.", as this seems to be unlikely, especially considering that the college in question was in fact founded one year after the development of Pascal. Should no citation be added within one week, I will remove this statement. —Preceding unsigned comment added by 195.194.148.2 (talk) 11:48, 26 September 2007 (UTC)
Mike Slater did make it famous, he also wrote a book in which he included many Pascal scripts, the book sold mainly to students of the college and was never officially published. —Preceding unsigned comment added by 90.200.27.251 (talk) 16:14, 30 September 2007 (UTC)
- Lecture notes used only at a single
universityhigh school usually don't count as "making something famous". If this is an exception, it needs sources - extraordinary claims need extraordinary evidence. –Henning Makholm 21:49, 1 October 2007 (UTC)
I'm somewhat mystified as to why there's been no mention of Michael Slater at all within the article so far! He did a lot of work after becoming one of the first few people to use pascal and discovering how apt it was at teaching his students structured programming. I don't believe that he was working at the Blackpool Sixth Form College at the time, however I did have the chance to see his brilliant work, "Pascal And Me: The Early Years" which was only ever sold to students after being rejected by two computer book publishers. (Parts of comment deleted due to WP:BLP concerns. –Henning Makholm 21:51, 1 October 2007 (UTC)) If anyone does have any more information on him, where he was working at the time or a copy of the book which was passed around students and staff at several teaching universities then I'd be very interested to hear of it.
I have a copy of this book, I can dig it out if you would like to see it Im sure we can come to some sort of arangement? —Preceding unsigned comment added by 78.144.224.151 (talk) 13:55, 4 October 2007 (UTC)
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? :-)
--Samiam95124 14:04, 6 December 2005 (UTC)
To keep the neutral point of view following should be deleted:
"Today, it [Pascal] remains popular mostly as a teaching tool."
you can find a lot new Pascal/Delphi programs, tools, sources, books and articles in Internet. There are scientific programs, games, system tools etc.
Also,
"However, C is actually more Algol-like than Pascal regarding (simple) declarations, retaining the type-name variable-name syntax which Pascal abandoned to allow for (easily read) complex type expressions and a better perceived clarity in educational situations."
This clarity is better not only for educational situations, but also for development in many cases. For example, it is very useful to describe a new algorithm. So, today many authors use Pascal or Pascal-like syntax for their papers.
Tim32 15:26, 7 October 2007 (UTC)
Agreed - go ahead and delete them.
Comparisons with C
I don't believe the section "comparisions with C" belongs in this document. First of all, there is another page that already compares Pascal and C. Second, are you going to compare every other language with Pascal here? Finally, how is any of that relevant to finding out what Pascal is? —Preceding unsigned comment added by 66.28.253.185 (talk) 00:37, 11 October 2007 (UTC)
-- Agreed!--Tim32 00:16, 14 October 2007 (UTC)
- Some of the wordings in the section has an unpleasantly argumentative sound, as if the point were to compare Pascal with C to find out which is better. That would have no good place in an encyclopedia. On the other hand, deleting the entire section would throw out quite some amount of child with the bathwater. It does make sense to present the syntactic look-and-feel of Pascal by pointing out what it does different from other languages, and it does make sense to let C be the comparison. The two languages sit quite close in the design space of all possible programming languages, which makes a comparison of their superficial features meaningful in the first place, and many readers will already be familiar with C-like syntax (especially those who have been taught programming after Java became hot, around the dot-com boom).
- Particularly such matters as the semicolon seem to be presented most effectively by contrasting with how semicolons work in C, but I think it is also prudent to note explicitly that Pascal and its successors is more word-heavy and less symbol-heavy than the other main branch of Algol derivates. –Henning Makholm 00:45, 14 October 2007 (UTC)
- Can you address why this information needs to be here, instead of the copious page on the subject already linked at the bottom of the page? (Pascal and C) —Preceding unsigned comment added by 66.28.253.185 (talk) 00:12, 17 October 2007 (UTC)
- Because it is information about the character of Pascal, not some kind of weird symmetric difference between Pascal and some other language. The fact that the best presentation about these features of Pascal is by contrasting with other possible choices is quite incidental to the basic fact that the purpose of saying it is to present Pascal. –Henning Makholm 16:38, 17 October 2007 (UTC)
Set types
The classical Pascal, contrary to other programming languages, offers a unique feature of explicit representation of the set types.
if i in [5..10] then...
is faster, than
if (i>4) and (i<11) then...
See, N.Wirth, Algorithms+Data Sructures...
Source formatting
I noticed that the Pointers section regarding 'with' statements in Pascal shows 'with' not highlighting in the code example.
It seems that the source lang="pascal" definition used on wikipedia must not somehow recognise that 'with' is a reserved word in Pascal.
For example:
with onething do
begin
anotherthing := 1
end;
How can this be updated?
Reception section is unbalanced
The reception section indicates that there are critical and complimentary opinions. Only critical responses are covered. If both exist, both need to be covered. --Elliskev 15:29, 25 February 2008 (UTC)
The pascal compiler implemented in Fortran
The article states that: Niklaus Wirth reports that a first attempt to implement it in Fortran in 1969 was unsuccessful due to Fortran's inadequacy to express complex data structures. There are several sources which support that claim. I have also found claims that the Pascal compiler written in Fortran was finished and rejected afterwards. Has anybody access to the source code of this first pascal compiler or other old pascal compilers? Georg Peter (talk) 07:41, 28 June 2008 (UTC)
- I doubt that the FORTRAN compiler still exists. I understand that the author was Edouard Marmier who was also jointly credited with Urs Ammann and Rudy Schild for the second attempt to build a Pascal compiler. This was written in Pascal and completed in 1970. I believe he is the Ed Marmier at http://www.marmier.com
- You can see a 1972 version of that ETH CDC6000 compiler and other early Pascal compilers on Scott Moore's Standard Pascal website at http://www.standardpascal.org Chris Burrows (talk) 13:02, 28 June 2008 (UTC)
- Besides Scott Moore's Standard Pascal website, where the oldest compilers are only available as scanned listings and not as editable text (see: http://www.standardpascal.org/CDC6000pascal.html), are there other places where the source code of old pascal compilers can be found (preferably as text file)? Georg Peter (talk) 10:11, 15 July 2008 (UTC)
Origins
Did some quoting of Wirth (on HOPL-II). The question remains, whether the copyright remains with Wirth (as he was quoted in the book (where the editors don't even purport to have contributed anything original)), or if it still belongs to the authors, or the publishers. Now, I have written some changes at the beginning of [this page], and I intend to leave it upon the more experienced authors and WP professionals to decide on whether my particular quoting should be edited or not. —Preceding unsigned comment added by Gwrede (talk • contribs) 00:01, 10 April 2009 (UTC)
This article is not about Delphi (Object Pascal)
Some anonymous user keeps adding a link to a Delphi tutorial. My understanding is that this article is about the original Pascal language as defined by Niklaus Wirth and later adopted as a standard in ISO/IEC 7185. Delphi is an implementation of an object-oriented derivative lnguage commonly known as Object Pascal, which has its own article. I am therefore reverting that change again. -- Tcncv (talk)
- Delphi has its own page as well. I agree with your deletions. jbolden1517Talk 04:42, 10 April 2009 (UTC)
Semicolons revisited
As previously discussed years ago, semicolons are statement separators in Pascal, not statement terminators. This use is in notable contrast to the syntax in many other programming languages, such as the C family. The semicolon is also used to separate (not terminate) the cases of the case statement, as in the last code fragment in the Control structures section. No semicolon is needed after the write('two') statement. The presence of a dangling semicolon introduces an empty statement.
This is quite wrong.
While it is true that no semicolon is _needed_, one is always permitted.
It does _not_ create an empty statement.
ISO Standard 7185 explicitly provides the option of a redundant semicolon before 'end'.
Look at section 6.8.3.5.
This was done specifically to remove an editing 'gotcha' when statements are added,
removed, or repositioned.
-- Bill Findlay 17:10, 5 September 2009 —Preceding unsigned comment added by 212.159.101.165 (talk)
I have removed the recently added semicolon to restore that code to its longstanding form. This is consistent with the rest of the article which avoids introducing empty statements -- Tcncv (talk) 03:55, 5 September 2009 (UTC)
- I stand corrected. Yes, it's an optional semicolon, not an empty statement. I was thinking statement-sequence rather than statement. I have to admit my practical experience with Pascal was back in my academic years, which were pre- ISO 7185. We used both PL/I (statement terminator) and Pascal (statement separator) and we got points taken off if we did demonstrate that we knew the difference. Shall I assume that you are also an old-timer – the same Bill Findlay listed in the credits of the standard?
I'm afraid that I am indeed the old-timer you identify. 8-)
- On a quick review of the standard, it appears to me that the semicolon is still used as a separator, but the presence of a empty statement and a few optional semicolons in the syntax covers most of the cases where someone thinking statement-terminator might get tripped up. The empty statement (section 6.8.2.1) allows a semicolon before the END in a block statement and before the UNTIL of a repeat statement. Optional semicolons in the syntax for both the record type declaration (section 3.4.3.3) and the case statement (section 6.8.3.5) cover some additional cases. However, and please correct me if I am wrong, there is still not an allowance for a semicolon following the statement in the THEN clause of an if statement, when followed by an ELSE clause (section 6.8.3.4).
You are correct.
The difference from CASE is that IF statements do not admit statement sequences.
Allowing a semicolon before ELSE would cause a local ambiguity that would
necessitate back-track parsing.
- So to return to the question of whether of not to include the optional semicolons and/or empty statements, I am of the opinion that we should leave them out. This would be consistent with the original reports by Niclaus Wirth. Also, with few exceptions (I counted five), the ISO 7185 standard also leaves them out of its examples. I of course will yield to consensus if it goes the other way.
I'm not greatly bothered , but for my taste it's neater with them in.
- Either way, it might be wise to include a short section discussing statement separators vs. statement terminators, and the accommodations made in the standard towards the latter. I suspect many of our readers now days are more likely to be familiar with languages in the C family, and would benefit from such a discussion. A couple of questions though: (1) Would if be accurate to say that the statement separator syntax was inherited from ALGOL?
Absolutely, yes.
- (2) Has the empty statement always been in Pascal, or was it introduced with the Revised Report?
{Consults very old compiler listings.} It was always there.
- I have added a section Semicolons as statement separators based in part on your input. Feel free to make any corrections or clarifications as you see fit. And thank your for your contributions – both past and present. -- Tcncv (talk) 21:42, 6 September 2009 (UTC)
- The empty statement wasn't mentioned in Wirth's Nov 1970 Pascal Report (TR1). It was included in a new section 9.1.4 in his July 1973 Revised Report (TR5). http://www.inf.ethz.ch/research/disstechreps/techreports/index?range=100 Chris Burrows (talk) 08:12, 8 September 2009 (UTC)
- Thank you for pointing out the error and for the link. I have updated the section. -- Tcncv (talk) 00:21, 9 September 2009 (UTC)
Stuff removed from Boolean data type article
The following section was removed from the article Boolean data type:
begin removed text
Boolean is a basic data type provided by Pascal. Its definition and uses:
(* declaration in system or standard*)
Type
Boolean = (False,True);
(* usage *)
var
value: Boolean;
...
value := True;
value := False;
if value then
begin
...
end;
Note that values outside the enum are not defined. Some compilers like Delphi have as extension special Boolean type that map onto C numeric types for interfacing purposes. (Delphi: bytebool,wordbool,longbool)
end removed text
Is there a place for this text in the Pascal-related articles? Perhaps in the Wikibook? Thanks, and all the best, --Jorge Stolfi (talk) 23:52, 30 December 2009 (UTC)
Further Updates
I have added some more details to the sections Pointers and Criticism. I also added a pair of references. Hopefully, it will read more clearly and add further info. Dmacgr 22 (talk) 07:20, 30 June 2010 (UTC)
pascal80
back in the mid 1980s I programmed in Pascal-80 using Radio Shack Model 4 with z80 microprossessor. a simple google search of pascal80 reveals its history here: http://www.trs-80.org/pascal-80/. If possible, could someone add/amend this the the already existing history of this article. thanks. — Preceding unsigned comment added by Gizziiusa (talk • contribs) 03:06, 22 September 2011 (UTC)
Historical Accuracy and Neutrality
I get the impression that the article was originally produced by a Pascal hater, but was eventually taken over by Pascal lovers. In its current form it doesn't seem to express a neutral point of view.
Several assertions in the history section need citations, and at least one assertion is inaccurate: the original intention of the language was exclusively as a teaching tool (Wirth himself stated that many years ago) so a statement contradicting this without any reference to support it is particularly unfortunate, especially since the sentence has a citation (supporting the "structured programming" part of the statement) that states "Pascal was designed as a simplified version for educational purposes of the language Algol, which dates from 1960", directly contradicting the article (the cited document also contradicts the dates given in the fron piece of the article, giving 1971 as the year in which Wirth designed the language, so what should we make of that? Perhaps citing something not particularly reliable is not a good idea). This error is repeated (again without any supporting citation) at the beginning of the next section (Brief Description).
Some assertions in the history section are possibly correct but certainly misleading; the statement that "Variants of Pascal have also frequently been used for everything from research projects to PC games and embedded systems" can easily be read as asserting that these uses of Pascal variants have been used in such fields as often as variants of C++ or of Fortran or of Lisp, which is certainly untrue, and while they have certainly been used more frequently in those contexts than for example SNOBOL and its variants the word "extensively" tends to mislead; the statement "Newer Pascal compilers exist which are widely used" could be taken as meaning that compilers for the 1970 version of Pascal are widely used, since no attempt is made to distinguish the new from the old, but the supporting citation shows only Delphi at above the 1% level (and it's not even based on frequency of use anyway, but on measures like number of people "qualified" in the language, which is presumably inflated for Pascal because Pascal is used as a teaching language).
The article would be greatly improved by structuring the description of the language (section 4 and its subsections) so that it makes clear what was in the original Pascal and what was not, since that would give a clearer view of the history - but that may not suit those who wish to claim that it Sprang into being as a superb as a useful general purpose programming language at birth, rather than taking quite some time to evolve to be capable of use for large scale programming Michealt (talk) 19:21, 24 February 2011 (UTC)
Your comment is not entirely NPOV either. I'm pretty sure that Pascal was used more in those fields its heyday (before say 1990) than e.g. C++. E.g. most unix systems in the eighties had a Pascal compiler, and so did many mainframes. Even if only for the simple fact that C++ did not exist or was an alpha level research project. If you want to make such remark, carefully keep track of time periods and annotate them (and the article could do better there too, certainly). I've never encountered either LISP or SNOBOL outside the academia in that period either (and even in academia only sparingly since I was mostly involved with physics/chemistry departments, not math) 88.159.64.210 (talk) 11:39, 29 April 2011 (UTC)
- Well, commercial use of LISP (in its various forms) was actually less in the 90s than in the 80s (use started growing again aftter the 90s) and it was certainly used outside academia in the 70s, including the period before the first commercial Pascal compiler in 1975. Pascal was certainly used more than C++ before 1990 ) but it is plainly false to say C++ didn't exist before 1990 or was an alpha level research project - GCC C++ support was released in Dec 1987, which suggests that there was a lot of interest before then, and C++ was usable on UNIX (SUNOS, IIRC) a year or two before that (that earlier thing was not a real compiler - it generated C code + bits of some intermediate language for which there was an interpreter, into which the compiled C code had to be linked). Some other languages were much more popular than PASCAL (or LISP) too, for example CORAL (a stuctured programming language that antedated PASCAL by about 6 years) with its variants CORAL 64, CORAL 66, POCORAL, and so on was very widely used, especially in the defence industry but also in telecomms, I used it in 1967/8 when I worked for English Electric so clearly it was used in Engineering as well, and the CORAL compiler certification procedure was used as the basis of the US MOD ADA compiler certification procedure, so it spread to that side of the pond too. As for my comment not being NPOV, it's hard to see how you can claim that. It's clear (not only since Wirth said so himself, but also since some of the restrictions would have been intolerable in a language for serious non-teaching use) that the first version was designed as a teaching language only so stating that is stating fact not POV. There was no commercial compiler before 1975, so clearly it was less used commercially than other languages at least until that date. The statement about extensive use does not restrict itself nether to dates after 1975 nor to dates before 1990, and does seem to suggest that it was something that got at least the same level of use as COBOL, FORTRAN, CORAL, C, C++, ADA, and so on, and really should say when this extensive use happened, how extensive it was, and which versions were involved; and since it doesn't restrict itself to before 1990 why should languages which took off after that date be excluded from comparison? I will make one definitely POV statement: MODULA is a better language than any version of PASCAL - and leave you to guess whether that's my POV, or Niklaus Wirth's POV, or both. Michealt (talk) 02:33, 24 October 2012 (UTC)
Managed pointers
The article states that "What these languages [Java and C#] call "managed pointers" were in fact foreseen by Wirth with the creation of Pascal." If "managed pointers" means "garbage collected object references", this is incorrect; Wirth's original Pascal did not have GC, and programmers had to manage the allocation and deallocation (dispose) of objects themselves, just as in PL/1, C, and C++. If "managed pointers" is supposed to mean something else, then it needs to be clarified. — Loadmaster (talk) 16:26, 12 September 2012 (UTC)
- I removed it, since it's unclear what is meant by a "managed pointer" (per Pascal), and it's not sourced. — Loadmaster (talk) 20:17, 19 November 2012 (UTC)
I think he confused "managed" with the "safe" concept. 88.159.71.34 (talk) 08:26, 8 January 2013 (UTC)
More Pascal History in the 80s
Pascal drove Corvus Systems, a 68000 box early 80's which featured networking, document editing with images, scsi drive: and pascal run-time editor and full sourced apps in pascal. Amazing but less available and more pricey than the IBM PC. — Preceding unsigned comment added by 72.209.222.174 (talk) 01:19, 1 July 2013 (UTC)
Compound statements
There are no examples of multiple statements (compound) in control structures. Ardjussi (talk) 17:03, 30 April 2014 (UTC)
GNU Pascal Compiler
"is one notable exception, being written in C". And the GNU C compiler (the compiler used to compile GNU Pascal) was originally written in Pascal. It was ported to C to make it more portable. —The preceding unsigned comment was added by 150.101.166.15 (talk) 12:54, 22 June 2007
- Not exactly. According to the history of GCC, Stallman attempted to port an existing compiler written in Pastel (a variant of Pascal) to C, but abandoned the effort when he discovered it would take too much stack space on the limited 68000 hardware he had available. He did re-use the C front-end he had written (presumably in C). So it would be more accurate to say that the original GCC compiler was written in C, but (perhaps) was based on the Pascal code from a pre-existing compiler. — Loadmaster (talk) 18:34, 30 April 2014 (UTC)
Pascal-FC
This is a "variation derived from the pl/0 compiler"? The pl/0 compiler was a teaching excersize, completely unrelated to the language Pascal. It isn't a dialect. Its not even similar. It should be moved elsewhere. — Preceding unsigned comment added by 74.121.22.10 (talk) 01:09, 16 July 2014 (UTC)
popularity?
I learned Pascal in the early 90s when it was very popular. Now, colleagues in the field, say it is obsolete. None of the IT undergrads at my school know it and few have even heard of it. What is its current status in general? http://pascal-central.com/ppl/chapter5.html says it "is" still popular, but that source is 13 yrs. old. So is the pascal page: http://pascal-central.com/ppl/ .211.225.33.104 (talk) 07:19, 16 June 2014 (UTC)
It's still popular, well up to your definition of "popular". You could just search "Lazarus", "Free Pascal", "Delphi", "Smart Mobile Studio" and any other living modern implementations. My favorite google query is: ("made in" OR "made using" OR "made with" OR "written in" OR "written using" OR "written with" OR "created in" OR "created using" OR "created with") ("pascal" OR "delphi" OR "lazarus" OR "freepascal" OR "free pascal"). Or you can simply look at Lazarus, Free Pascal and Delphi application gallery. Leledumbo (talk) 08:47, 17 June 2014 (UTC)
It really depends on your definition. A language with the name "Pascal", but most of the type security ripped out was marketed as Borland Pascal and is still popular. Type security, and the concept of virtual machines as a basis for distribution was reinvented by Java and C#, the later reintroduced Pascal pointers as "managed pointers". These languages are the true legacy of Pascal, doubly amusing if you consider the designer at Borland was the one who went on to design C#.
Your idea of popularity is number of users, a reasonable measure of bulk use if not necessarily quality, then I think you are looking for UCSD Pascal followed by Borland Pascal followed perhaps by Delphi. The reason I say this is that UCSD had far more users than the original Pascal language ever did, being mainly confined to mainframes and minicomputers. This is a dialect that goes:
Pascal-P2 -> UCSD -> Borland -> Delphi
P2 was a subset of original Pascal, that was adopted, substantially intact as UCSD Pascal, and Borland used many or most of the language features of UCSD. Then Borland later came out with mostly compatible Delphi.
— Preceding unsigned comment added by 74.121.22.10 (talk) 01:34, 16 July 2014 (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)
For point A (Pascal and C are both strongly typed):
int a[10];
void prtarr(int *a)
{
while (*a++);
}
void main()
{
int a[10];
prtarr(a);
}
— Preceding unsigned comment added by 74.121.22.10 (talk) 01:15, 16 July 2014 (UTC)
What about:
type
TSomeEnum = (seVal1,seVal2,seVal3);
...
var
e: TSomeEnum;
b: Byte;
...
e := <arbitrary integer value>; // compile-time error
b := <any integer outside Byte range>; // compile-time error
vs
typedef enum { seVal1,seVal2,seVal3 } TSomeEnum;
TSomeEnum e;
unsigned char b;
...
e = <arbitrary integer value>; // not even a runtime error
b = <any integer outside Byte range>; // a warning at worst, with some compiler switch
It's clear which one is strongly typed here. Leledumbo (talk) 02:14, 17 July 2014 (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
(It also doesn't have a notational difference between a cast and a conversion) you are thinking of Borland Pascal. Original Pascal has only the covertions:
1. ord() - convert ordinal to integer.
2. trunc()/round() - convert real to integer.
3. char() - Convert integer to character.
These conversions are far, far (far) from C type conversions.
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.
Remove criticism and reaction sections?
Per Bilbo Fragginz:
- Removed criticism and reaction sections entirely, criticism was not badly written, but seemed biased, and had been tagged as such. Reaction section was badly written and unsubstantiated. Cited a source for ISO 8651-2:1988, doesn't have page
I agree with this analysis. I don't agree that the next thing to do is to delete these sections. Per WP:BRD, I've restored, and started this talk. Comments? --A D Monroe III (talk) 22:29, 21 August 2014 (UTC)
Digraphs and comment syntax
Both are not mentioned in the article. :-/ --RokerHRO (talk) 14:21, 7 November 2014 (UTC)