Talk:Comparison of Pascal and C

From Wikipedia, the free encyclopedia

Contents 1 Modern C and Modern Pascal 2 "needs to be looked over by a expert" 3 J7 changes 4 Pascal separators 5 The blue, blue sky 6 A complement for you 7 Deletes 8 Dynamic arrays 9 Why is this page here ? 10 General comments 11 Identifiers 12 Nested functions in C99? 13 Borland does not rule 14 Language Caveats 15 Title 16 Cleanup tags 17 POV 18 Simple Types 19 C function pointers versus Pascal functional arguments 20 Whether Article Should Exist? 21 Type escapes 22 LL(1) parseability 23 Working on Replacement 24 Semicolon use 25 Is ; statement?

[edit] Modern C and Modern Pascal

This page needs to be separated into more specific pages.

Page 1: Comparison of Original C and Standard Pascal.

Page 2: Comparison of Modern C/C++ and Modern Pascal

The word "Pascal" is extremely vague. The Pascal that is in major use today such as freepascal and delphi are more comparable to modern C and modern C++ compilers. One cannot compare modern C to standard pascal unless explicitly stating so. Nor can one compare modern pascal to B language if the comparison is between pascal and C. Nor can we bounce back and forth comparing both standard pascal to old C and new C to standard Pascal since it is inconsistent, confusing, and chronologically disorganized.

The page, as restated, specifically defines what Pascal it is talking about, which is original Pascal as defined by Wirth and standardized by the ISO 7185 standard. These languages are virtually identical and form the Basis of unextended Pascal.

Please distinguish Modern Pascal from Standard Pascal. In order to obtain a chronological reference, one would have to state the "current Pascal in use in freepascal 2.0.4 and in Delphi 7 compared to the current C used in GCC and Visual Studio". Also, neither current C++/C nor current Pascal compilers are standards compliant. Define what "standard pascal" is and what year it is you are talking about, and define what "modern pascal" is by referencing the year and compiler versions, and define what C and C++ is since no C compiler or C++ compiler implements any "pure standard C". --LFiveZeroFive

Not even close to being true, there are several completely standard compliant compilers available, from GCC to IP Pascal, Dr Pascal, Irie Pascal and others. The same goes for C/C++, for which standards compliance is the rule. Honestly, I don't know where you are getting this information from. It would be more productive to list compilers that are NOT compliant than to list those that are, since virtually all compilers outside of Delphi are compliant, and on the C/C++ side it is hard to find ANY that aren't.

-- Yes, this page may be separated into more specific pages:

1) Comparison of Original C and Standard Pascal.
2) Comparison of Original C and Extended Pascal (Standard: ISO/IEC 10206; ANSI/IEEE 770X3.160:1989).
3) Comparison of Original C and Turbo Pascal 5.0.
4) Comparison of C++ and OO Pascal/Delphi.
5) Comparison of Original C and C++.
6) Comparison of C++ and C#.

(5,6): See, book Andrew Troelsen, C# and the .NET platform, Chapter 1, Apress, 2001.

Tim32 21:09, 11 October 2007 (UTC)

I certainly agree, but will list a few points.

1. The continuous characterisation of Delphi and Turbo Pascal languages as "modern" and other versions of Pascal as, by implication "outdated" is unnecessary and serves you no purpose here other than starting a petty fight with users who otherwise might agree with you and help you. Borland created a dialect of Pascal (an incompatible one). If that dialect is good or bad is not the subject here. Borland is Pascal as far as it is compatible with the language Pascal, which Niklaus Wirth created. There are plenty of implementations of Pascal outside of the Borland family, including GCC, IP Pascal, Dr Pascal, Ire Pascal and others (and that is only counting implementations that are still actively supported). In short, we could be in complete agreement here, if you (and others) would simply knock off the namecalling.

2. C and C++ are different languages, so certainly any page involving Delphi or Turbo should consider the object oriented features separately. To do otherwise is to treat C improperly, ie., to compare apples to oranges.

3. Are the Turbo and Delphi dialects so different that they require different pages? I would suggest that if you believe they do, then you are comparing not just the language, but the libraries and external interfaces it supports, since the biggest difference between Turbo and Delphi is Delphi's extensive class library. I think the library that the implementation supports and its language are different issues.

In short, I think a "delphi vs C++" page is the best place to start, since it compares two fairly equivalent, and currently supported languages. After this is created, then folks here can decide if they need more. Right now, we don't see anyone volunteering to create even one page, much less the six different pages you are avocating! —Preceding unsigned comment added by 66.28.253.185 (talk) 20:21, 26 December 2007 (UTC)

[edit] "needs to be looked over by a expert"

Hi, I wrote this page, because of a request by another user. I don't work on this page anymore. I looked it over briefly, and in the year that I have left it, it now has several factual errors inserted in it. I don't fight over Wikipedia issues anymore, I don't have the time or inclination. Simply be aware that this article is no longer very factual, and is quite likely degenerating into being mostly fiction.

Scott A. Moore

Can you give us a few examples of such factual errors, so I, or someone else, can fix them? /HenkeB 03:12, 7 September 2006 (UTC)

Because it does not, in fact, cover the language Pascal, but rather Delphi. It also is not very factual about languages in general. For example, it talks about the calling convention differences between Pascal and C. Neither of these languages, C nor Pascal, has a "calling convention". If you don't believe me, please look at the standards documents for either languages. The calling convention is up to the compiler, not the language.

In theory yes, but in practice one usually has to accept some low level conventions to enable compiled code to efficiently fulfill the semantics of a particular language on real computers. There were no standard documents for K&R C (other than the informal white book) but in most K&R C compilers the caller was responsible for removing pushed parameters from the stack, and parameters were pushed right to left so the first (such as the format-string in printf) was accessible on a known fixed offset off the stack pointer; this was (and probably still is) the de facto standard method for permitting variable and/or runtime-sized parameter-lists in C. /HenkeB 09:33, 25 June 2007 (UTC)

In fact, no it isn't. I don't really have time to lecture you on compilers, pick up a book. In fact, stack based passing was popular in the 1980s and early 1990s, and even then, mainly on low performace microprocessors. It is inherently NOT a register based calling convention (hence the name "stack"), and virtually all modern operating systems and languages use register based calling conventions (you have perhaps heard of Windows, or GCC?). —Preceding unsigned comment added by 66.28.253.185 (talk) 00:23, 17 October 2007 (UTC)

You are rude and appear quite angry, but I will try to explain some basic things for you anyhow: A C or Pascal compiler can only pass a few parameters directly in registers, typically around 1-3 on x86 machines (Windows), before it simply runs out of free registers. For calls with more parameters, it must either dynamically (to allow multi-level calls) allocate a data area in which to store the rest of the actual parameters, or use the stack (which is inherently dynamic - albeit in a rigid manner). There are CPU architectures with enough registers to use register-allocated parameters in almost every case, but x86 is certainly not one of them (and not a "low performace microprocessor"). Also bear in mind that, even when parameters are passed 100% in registers, the registers must sometimes themselfs be preserved (on a stack) to allow for multi-level and recursive calls. HenkeB 02:39, 20 October 2007 (UTC)

again, NONE of this has any bearing on the language as seen by the user, which is why neither the standards for C nor Pascal includes such information. —Preceding unsigned comment added by 66.28.253.185 (talk) 20:34, 26 December 2007 (UTC)

All in all, this article is deceptive (it does not in fact cover the languages it proports to, but rather someone's "favorite" implementation), erroneous (as I have described above), and, as the writer at the bottom of this page suggests, it performs a comparision between completely unrelated languages.

I wrote the original of this page. It has become, and is, a great example of everything that is wrong with Wikipedia. All of the distortion, special interests, and ignorance of a publically edited page. Sorry, it just is.

--Samiam95124 23:05, 2 March 2007 (UTC)

I and others have fixed the above complaints and consider the issue closed. —Preceding unsigned comment added by 66.28.253.185 (talk) 20:32, 26 December 2007 (UTC)

[edit] J7 changes

1.

" Some newer pascal compilers allow arrays to be declared in a way more similar to C

var x = array [0..9] of integer "

The above statement is valid Pascal and has always been valid Pascal.

2.

Certain newer Pascal compilers have a predefined string type, which works as a NULL terminated string similar to a char array in C.

I think you are talking about UCSD/Borland strings, in which case the statement is not correct. Those strings don't use a zero terminator.

(I think he talks about Delphi, which has a null (and double null since D4) terminated string type for easy passing to C. However it is only #0#0 terminated for C's sake, since there is still a separate length, and the type can contain #0's too. IOW, proper pascal code shouldn't loop with a check for #0. 88.159.87.12 10:00, 23 July 2006 (UTC) )

3.

Record types - a 3 bit integer is actually 0..7 not 0..3 (which is 2 bits)

Which is germane to the example how ? The article does not state it should fit in any particular number of bits. Its just saying that the construct is equivalent to the bitfield specification in C.

4.

writeln('the sum is: ' + x);

What language are you quoting? That statement is invalid in every Pascal in existence, including Borland. The statement you replaced this with is perfectly valid.

--Samiam95124 20:31, 17 December 2005 (UTC)

[edit] Pascal separators

"This difference stems from that Pascal treats the whole program as one very long, run-on sentence, and therefore all statements except the last end in a semicolon and the last ends in a period; whereas C do not treat a program as a sentence and simply uses a semicolon to end a statement"

This is dismissive and unprofessional. I won't allow this page to descend into a "language war" page.

--Samiam95124 18:03, 17 December 2005 (UTC)

How is this "dismissive"? And how is this a "language war"? This is the reason behind Pascal's use of the period (.) after the final "end". It is as neutral as it can get.—Gniw (Wing) 19:35, 17 December 2005 (UTC)

The sentence "This difference stems from that Pascal treats the whole program as one very long, run-on sentence" is:

1. Derogatory towards Pascal.

2. Incorrect from a professional Pascal compiler writers point of view. A program is not a sentence (in either language). In the standard for both language nowhere does the term "sentence" appear, in both standards the term "statement" appears.

The difference between Pascal and C is succinctly stated as "In Pascal, the semicolon is a statement separator, in C it is a statement terminator". And this, indeed, is what is says now.

This paragraph is obviously written by someone biased towards C and against Pascal. This is (again) not the "war between Pascal and C" page, it is designed to inform programmers who might want to learn what the differences between languages are.

--Samiam95124 19:55, 17 December 2005 (UTC)

That was a beautiful way to express how Pascal is done. I'd always seen the "." at the end as a very ugly wart, but it all makes sense if you view the program as a great big sentence. AlbertCahalan 07:35, 24 April 2006 (UTC)

This has nothing do with run on sentences. If we are going to make immature statements, then I'm going to say that Rob Pike (a C programmer) stated that C functions should be written like_this_because_english_prose uses spaces rather than ThisStyleHere. So one could argue that C is trying to become English prose, when in fact Programs are not English prose and should not be designed like English prose. Let's try and be rational and stop making silly presumptions though. The reason that Pascal uses the period is so that one can distinguish the end of the program from the end of a procedure. During editing when you are half a sleep working long hours, it can be helpful to know that this is the end of the program rather than the end of the procedure. Without the dot it can cause silly mistakes, such as the program being ended prematurely when you intended the procedure to end instead. The rationale for leaving out the semi colon in an else statement is similar. If a coder deletes a line of code, a lack of semicolon catches silly mistakes if else was deleted by mistake or late in the evening when one is half asleep, or when another programmer has modified the code on a multi-developer project. Compiling the program or unit where a semi colon is missing and no else keyword follows let's the programmer know that someone deleted the else statement without thinking about the previous line of code. User:LFiveZeroFive

[edit] The blue, blue sky

A common complaint here from many Pascalers is that their specific version of Pascal has "solved" any "lack" vs. C. This creates a strong temptaton to annotate this article to "show" how one particular Pascal implementation has completely closed the gap with C.

I added the "Blue Sky Pascal" to hopefully address why I think this is better left to a specific page on a specific Pascal, rather than included wholesale here. The basic point to understand is that a combination of Pascal and C is no longer Pascal nor C. Pascal loses its type safety, and C loses its simplicity. While such combinations might be interesting elsewhere, the comparision of Pascal and C as distinct languages would lose its flavor just as much as a comparision of steak and Spam if the two were mixed together in a blender.

Pascal has values that are distinct from C. The fact that the common memory has forgotten this is not germane to the facts of the matter. Java and C# may be heralded as a "revolution" in type safety, but that does not erase the fact that Pascal had such concepts some 30 years before.

[edit] A complement for you

I have to admit, this page has generated much less argument that I would have guessed, based on previous wars between C and Pascal users.

I really appreciate that most readers and editors only want a balanced view of both languages.

Thank you.

--Samiam95124 22:01, 22 November 2005 (UTC)

Yep, really good write. Thanks from a pascal and c programmer!

dunkelfalke

Indeed! It was a very nice read. Thank you and greetings from a nostalgic Pascal fanatic. -- ActiveSelective 07:24, 25 March 2006 (UTC)

I'd like to add my congratulations too for a very clear and well balanced article. David Heffernan 12th Feb 2007.

[edit] Deletes

If you delete a section, and don't provide what you think is a "correct" interpretation, then you are GOING TO GET REVERTED. I am sick and tired of people simply choping out sections they don't like. If you have a problem with how something is worded, then YOU reword it. Deleting does nothing to advance Wikipedia.

[edit] Dynamic arrays

The elided material was:

"The ability to both have arrays of any length, and be able to check them under language control, is often termed "dynamic arrays"."

Mr. Burroughs says:

Removed irrelevant / misleading / inaccurate refererence to dynamic arrays. 'Dynamic arrays' usually refers to arrays that can be resized at runtime.

Not sure I see the problem here. Many implementations of Pascal have varying ways to do this, and pretty much all of them qualify as "arrays that can be resized at runtime".

I would prefer if you are going to remove material like this, if you would instead reword it to your idea of "correct". We are trying to add information here, not remove it.--Samiam95124 04:00, 6 October 2005 (UTC)

[edit] Why is this page here ?

This page is here because I felt that a "head to head" comparison of C and Pascal was inappropriate to the Pascal page. At worst, it invites fights between the supporters of the respective languages. At best, it is logistically problematic (shall we add a section to every language comparing it to C ? All languages to each other ?).

A compromise was made to move that comparision here, and remove it from the Pascal page.

I have constructed professional compilers for both languages C and Pascal (and many others). I also use both languages on a day to day basis. So I feel I am qualified to make a comparision. I have tried to make the material as factual and unbiased as possible.

However, I will freely admit I am biased in favor of Pascal. It is, to me, simply a cleaner and more secure language. Feel free to contribute your C oriented point of view to the article.

However, I would appreciate it if both sides of the issue would refrain from adding the myths, distortions, and jingoisims that characterize the general C vs. Pascal debates. I'll give you a few, and I think you will get the idea.

• Pascal cannot do low level programming.

Pascal is used for low level programming all the time, and has been used to construct compilers, operating systems, and drivers, in addition to embedded work.

• C is unsafe, and causes the worm problems we see due to buffer overflow attacks.

There is nothing preventing C programmers from checking their buffers and arrays in general. This is lazyness, not a language feature.

• Pascal is inefficient.

Efficiency is up to the compiler. Using a C statement like x++ does not make your code more effcient because it compiles to an increment. Pascal compilers know how to change x := x+1 to an increment as well. In fact, there is very little difference between the efficiency characteristics of the two languages.

• C creates messy programs

I have seen Pascal programs that should be thrown away (quickly), and C programs that are beautiful. It's all up to the programmer.

• Pascal is restrictive, and won't let you do things.

Allan Turing showed that any computer can emulate any other, and that concept extends to programming languages. Pascal is not a "party hardy" language, nor was it designed to be. But every program that can be constructed in C can also be constructed in Pascal. It really comes down to if you value the extra type checking enough to do a little more work.

Yes indeed. You can write a Turing machine emulator in Pascal, then use that turing machine to implement a C compiler and C runtime... but it wouldn't be very fast or maintainable. (actually no, because a real Turing machine requires infinite memory) AlbertCahalan 07:32, 24 April 2006 (UTC)

Please also think logically about comparisons. Many comparisons appearing on the web compare apples with oranges. i.e., talk about features that C has, verses what Pascal had in 1972 (!) Did you know that C didn't used to have enumerated types, the "typedef" statement, and other features ? Pascal didn't stand still either. If you are going to compare to Pascal, compare to Pascal as it is, which in most editions has dynamic arrays, modular compilation, objects and other features.

If you are a Pascal programmer, get to know C before you make a comparison. If you are a C programmer, get to know Pascal. Comparing the language you use every day vs. the language you used back in college computer 101 isn't going to be a fair or valuable comparison.

Thank you for your attention.--Samiam95124 02:29, 4 Jun 2005 (UTC)

[edit] General comments

I don't have much time to spend on this right now, but I gave it a quick read, and cleaned up a few things. There are a lot more wiki links to add, for example, and the code samples should be presented in a fixed-width font.

Overall, I think it does a good job of illustrating the differences between the languages. I like it better as a separate article than as part of the C or Pascal pages. 209.193.109.10 23:40, 4 Jun 2005 (UTC)

Sorry - I wasn't logged in. Those comments are from: Gary D Robson 23:41, 4 Jun 2005 (UTC)

[edit] Identifiers

In the section "Identifiers", the author first talks about "identifiers", and then about "labels". I was under the impression that identifiers and labels are the same thing. If so, the word "identifier" should be used exclusively to avoid ambiguity. --Silver hr 09:28, 21 Jun 2005 (UTC)

Got rid of the obvious ones.--Samiam95124 00:32, 25 Jun 2005 (UTC)

[edit] Nested functions in C99?

Since when does C99 have nested functions? Have I missed something? I haven't read the standard. — JIP | Talk 09:47, 21 Jun 2005 (UTC)

Two of the more interesting additions to C99 were nested functions and structured VALUE parameters. Thats right, C is getting to be more like Pascal every day :-)--Samiam95124 00:34, 25 Jun 2005 (UTC)

Most C compilers have supported nested functions for many years, so C99 is simply a formalization of what was already widely practiced and implemented.

I sure didn't see that in the standard. Dear my, that would be bad taste. Data structures can logically nest. Functions can not. I try to imagine this at the assembly level... I guess there must be a jump over the inner function.  :-) Of course it is not done this way, because nested functions are an illusion. Nested functions create many weird scope-related problems. They also make the compiler's error messages less useful, because the compiler is less able to detect when a user has left off the closing "}". AlbertCahalan 07:28, 24 April 2006 (UTC)

That is a one sided argument. Look at it from two sides. One could argue that a lack of local scope procedures and functions in C leads to global spaghetti code since C does not have modules, namespaces, or units. Lack of local scope procedures and functions and units/modules pollutes the namespace in modern C or original C. Modern C does not support separate units or namespaces (while C++ does of course). There are disadvantages to local scope functions and procedures, but there are disadvantages to globals too. Functions and procedures not defined locally or in a separate unit can be as disaster prone as global variables at times, considering overloading and namespace pollution issues. Neither solution is the holy grail. I'd argue that most local scope functions in Pascal could be placed in separate units instead, but whenever the units are put in the uses clause it still means the functions and procedures are globally accessible - so local scope functions can still protect the namespace and still have their advantages. Another idea would be to have a Uses clauses inside the procedure, so that one could call a unit only inside the local procedure (near the VAR and CONST clauses). This way, scope would be protected and functions and procedures inside another unit could be local to one procedure only, while maintaining readability and separate compilation. One of the problems with nested functions is they can span across the screen vertically too far and loss of concentration occurs if the nests are deep enough and vertically long enough. LFiveZeroFive

GCC supports nested functions but C99 does not. C has supported passing objects having structured type as arguments to functions since the C90 standard (and returning them). Derek farn 11:11, 24 April 2006 (UTC)

[edit] Borland does not rule

Lots of Borland specific language items were added, such as type casting, creating strings from pointers, etc. This isn't "Borland and C", its "Pascal and C". If you want to compare Borland and C, please make that a separate page. There are MANY Pascal implementations besides Borland.

I cannot agree. Being a pascal programmer for a very long time I know that all major pascal compilers at this time support those features, including Free Pascal and GNU Pascal. I seriously doubt that you can find a still developed one that doesn't. --Felipe Monteiro de Carvalho 13:26, 27 August 2005 (UTC)

So? Borland is a highly extended version of Pascal. Your comments are entirely appropriate for a page which would be called "Borland Pascal and C". There is no real conflict here. Even if you feel that Borland is the dominant version of Pascal, this article is simply about Pascal in general, not Borland in specific. Please feel free to create a "Borland Pascal and C" page. You can even reference this page and add only what is different between Pascal and Borlands version (actually, versions) and C. This is pretty much the same rule that was applied for the Pascal language Page. It documents all Pascals, then there are specific pages on Borlands various versions of it. Even if you DID make this a Borland specific page, you would have to choose which version of Borland to discuss here, from Turbo to Delphi.--Samiam95124 22:30, 30 August 2005 (UTC)

I would like to call "Borland Pascal" "Borland Dialect" instead. I doubt which version(s) of pascal used today still leave the programmer to determine the exact length of a "character array". String has already become a primary type, with the 0th byte recoreded the length of it. (in Borland Dialect for sure; uncertein in Mac Dialect) Show me a guy that is still using non-"Borland Dialect" pascal for serious/not serious work nowadays. If you go to learn Pascal, it's next to impossible that you end up learning non-Borland dialect if you aren't specifically hate Borland. And where are those MANY implementations that doesn't favour the Borland Dialect? Give me one that is still actively developed and/or widely adopted these days. But maybe you are right. There should be two pages: one "Pascal and C (when they are in decades ago)" and one "Pascal and C (in today's world)" ;)

I am such a user of a non-borland dialect, and I have been using Pascal longer than Borland has existed, since 1980. There are many non-borland compilers, including GPC, IP Pascal, Prospero Pascal, Irie tools, DR Pascal, and I am sure others. I'm not going to get into a "who's more popular" argument. If you feel that a "Borland Pascal vs. C" page is needed, then by all means make it. There is no reason to hyjack a general Pascal page such as this one, and turn it into Borland only. Borland Pascal can have its own separate page, and I have even outlined some minimal requirements by which it would be appropriate to list Borland features on this page (namely marking them as Borland features). in short, no, other Pascals besides borland haven't in fact died out, and no, changing all the pages here about Pascal to be Borland specific is neither appropriate nor is it necessary. Borland has its own pages. Note that all implementations of Pascal obey this requirement. For each specific Pascal, there is a specific page, and the general Pascal pages talk mainly about what they have in common. There are specific implementation details on the general Pascal pages, but they are clearly labeled as to which specific Pascal is being mentioned. I also note that Borland's Pascal versions (there are more than one) are mentioned on the general Pascal pages more than ANY other Pascal implementation.

I'll make you a deal. I will be much more inclined to leave Borland specific references in if they are MARKED as Borland specific features. I also don't have a problem with talking about extentions to Pascal (as the article already does in places), if it is discussed in a general way. For example, "many Pascals provide a case statement default" does not pin it to one particular Pascal, and talks about Pascal implementations in general. I don't happen to be a Borland user, however, you will note that I have not tried to put specific features of the Pascal I use into this document, either. The rule with Wikipedia is NPOV, Neutral Point of View. Let's talk about Pascal in general (and C in general !).--Samiam95124 22:51, 30 August 2005 (UTC)

I like the idea of marking features from the extensions as this adds to the overall quality of the information and prevents the creation of a "Borland pascal vs C". What I would sugest is that we mark those features as "Object Pascal". Claiming that those features are Borland's is quite incorrect, specially with the advent of strong open source projects such as Lazarus, FreePascal, GnuPascal and others.

From http://en.wikipedia.org/wiki/Object_Pascal:

Object Pascal was a creation of Niklaus Wirth and Larry Tesler. It was created at Apple Computer in early 1985 through their collaboration. It added object-oriented extensions to the existing Pascal programming language. .... In 1986, Borland introduced similar extensions, also called Object Pascal, to the Turbo Pascal product for the Macintosh, and in 1989 for Turbo Pascal 5.5 for DOS.

As you can see "Object Pascal" is veeeeery old and well stabilished =) --Felipe Monteiro de Carvalho 01:56, 8 September 2005 (UTC)

Overall, I don't have a problem with this, but I do have questions about it. First, Apple has pretty much dumped its Pascal, so this seems to be a historical reference. Second, are you going to research what is and is not the same between Object Pascal and Borland? Most of the modifications I have seen appear to come directly from Borland's Pascal versions.--Samiam95124 20:53, 8 September 2005 (UTC)

I thing a good research on this subject would improve the page on the Pascal side. Fell free to research as weel =) --Felipe Monteiro de Carvalho 23:44, 9 September 2005 (UTC)

[edit] Language Caveats

I'm an experienced C/C++ programmer (15+ years). But I still sometimes make the mistake/typo:

if( a = 0 ) { ...

Which is perfectly legal C (though some compilers will warn about this). This mistake is impossible in Pascal, where comparison is = and assignment is :=

Actually, even if they were the same operator in Pascal, it would still not be legal, since assignment is not an operator in Pascal.--Samiam95124 04:00, 6 October 2005 (UTC)

I think the point is that regardless of the reason, this not all that uncommon C mistake is impossible in pascal, the pascal language rules prevents you from shooting yourself in the foot in this particular case. It's an important distinction when comparing pascal to C.

I don't make the point to be pendantic. There are major differences between the way C and Pascal treat assignment, and distinct reasons behind it. In C, assignment is an expression operator. In Pascal its a statement. This is why you can do assignment anywhere in an expression in C. To be fair to C, it does not overload the "=" operator, like (for example) Basic does. "=" means assignment, and there is a distinct equality operator "==". So to be accurate, the very common mistake of using assign where equality is meant is either due to the fact that assignment "looks" like equality, or the fact that equality and assignment are both operators, and so it is not an error to inadvertently exchange them.

In Pascal, the appearance of assignment as both a distinct tolken from equality (which C does share), and its restriction to a statement is quite deliberate. the ability of expression operators to perform assignment gives them the power to create "side effects", which Pascal considers "bad" (in that "gotos" and unstructured programming "bad" sort of way). The split between the languages is clear here. The C whitebook talks about "evaluating expressions for their side effects", and the operator ",", which means "discard the left expression result" is only meaningfull because it produces side effects.

Your last paragraph here makes a lot of sense, especially the comparison with "gotos", i belive this is material that would fit the main article well! /HenkeB 17:10, 25 June 2007 (UTC)

--Samiam95124 22:15, 22 November 2005 (UTC)

To be more accurate, if( a = 0 ) is almost never the actual intended operation, due to == and = being very easy to typo and very easy to overlook. IMO it is worthy to note this as a language caveat -- the fact C allows these kind of expressions lends itself to easily overlooked bugs, where a stricter language would not allow such mistakes. It's worthy to note that the DOD mandated ADA for a long time which has pascal style evaluation, and other language constructs which help make it a "safer" language than C. Speaking in general terms, Pascal is a safer language than C.

As much as I dislike this particular syntactic feature of C, I actually never mix these operators up. Probably due to my dislike of C's assignment operator unnecessarily breaking the well established mathematical meaning of the equal sign, with (the purely aesthetically unpleasant) == taking it's place. I suppose irritation makes you alert...

Appart from this and a few other things, I actually found C quite nice to work with, especially for embedded programming and other low level tasks (not being ironic). What bothered me the most were the lack of nested functions, the lack of semi-dynamic (stacked) arrays (missing in pascal as well), C's scalar-only semantics, and the ugly, unsafe and cumbersome assembly-like compilation model — almost three visibility levels (every name visible among files unless declared "static"), simple shared constants dependent on preprocessing and include files etc. What I liked the most were the {} notation, however shallow or superficial this might seem.

While I'm at it (and also being balanced), my personal problems with standard/turbo pascal was the inability to declare things inside begin-end blocks (such as "really local" variables) and the very rigid handling of arrays (length as part of the type), making programming harder without adding much extra security, as I see it.

These kinds of hurdles are central to most practical usage of the languages and must be possible to discuss (in a civil way) also in an article, without starting a "language war". It would be perfectly sensible to have two differrent point of views presented side by side to give a more complete picture to the reader; take C's scalar-only semantics for instance, to me it is a semantic limitation, to many C programmers it is an inherently elegant feature (or lack of). /HenkeB 17:10, 25 June 2007 (UTC)

I agree. Can you add this? I also make this mistake often in c++. --Felipe Monteiro de Carvalho 23:32, 5 December 2005 (UTC)

I agree as well, I too make this mistake often. Siddharthagandhi 03:01, 11 November 2006 (UTC)

I disagree. The safety argument is too general and carries a negative connotation. The description needs to be more specific. The mistake is (somewhat) common when writing C programs, but semantically improbable when writing Pascal programs. Because they have trained themselves to watch for it, experienced programmers are less likely to make the mistake, and more likely to spot it once they do make it. However, the mistake could increase debugging time, because the programmer would have to determine that there is a problem (which is not always obvious—especially with conditionals), locate its cause (which could take some time with large or complicated programs), and then fix it (which should be relatively easy once determined and isolated). The conclusion that one language is safer than another is for the reader to make, though it could be presented as a common opinion among Pascal (and even C) programmers. It should not be presented as a valid statement without some sort of qualification.—Kbolino 04:13, 28 January 2007 (UTC)

[edit] Title

Shouldn't this article be titled Comparison of Pascal and C to conform with standards? Also, I believe MirrorVax was correct in his category changes -- this is not an article on a programming language, its an article comparing two languages and should be labelled as such. .:.Jareth.:. ^babelfish 05:18, 18 December 2005 (UTC)

[edit] Cleanup tags

I've added four cleanup tags to this article:

• Tone: The prose in this article is written in an informal essay style, and it is interleaved with an excessive amount of sample code.
• Contradictory: The article contradicts itself in several places, most notably in the last two sections of text ("'Blue Sky' Pascal" and "Epilogue").
• Unreferenced: The article makes a number of unreferenced claims about the absence of certain features, especially in C. A careful reading of the C99 specification reveals many of these uncited claims to be false.
• Importance: What information does this article provide that is not already available in C programming language and Pascal programming language?

—donhalcon^╤ 05:57, 6 March 2006 (UTC)

The tag I agree on is the "Unreferenced" tag. Please explain the other three tags.

I removed two tags that ask users to make plain wrong edits:

• "Importance" -- First, this topic itself has been at the center of many discussion a lot of times. Next, reading both the C programming language and Pascal programming language I could only infer the differences, not find them. (you really want to move this stand-alone page into both C and Pascal pages? There are other tags for that suggestion. More importantly, apart from redundancy, it will make the C page about Pascal, and the Pascal about C, and editing impractical)
• "Contradiction" -- I found no contradictions. I only found that readers need to stay focussed in the part you mention, because a lot is said in only a few words and in a not so structured way. The article does need some help here, that's true, but
  • there is no contradiction between saying the languages are structurally very similar (if, for, while, functions, ALGOL-descendency) but the parameter type handling is different (very strict vs dynamic).
  • Also, there is no contradiction between the practical purpose of the different type handlings, and that a programmer could in principle program in such a way (too sophisticated for practice) that this difference is overrided.
  • Neither contradictory is saying that the evolution of compilers brings the programming closer together.

-- ActiveSelective 09:26, 25 March 2006 (UTC)

[edit] POV

While obviously this article was written with the best intentions, it suffers from numerous POV problems. As the article mentions it is hard to write an article like this, so I won't go and modify it. I'm coauthor of Free Pascal, so my opinions are POV as well.

However, that does not make my objections invalid. The article describes the original Pascal from the 1970's. It is a personal point of view that the modern Pascal has taken features from C and therefore would be equal to C. Facts are:

• • Modern Pascal is wildly more capable than the Pascal from the 70's.
  • Some features that were added are present in C as well, i.e. type casting, pointer arithmetic.
  • Many are not, i.e. units, strings, properties, interfaces.
  • C took features from Pascal as well, i.e. booleans, enumerations, nested procedures and var parameters.

Somehow the article has no problem comparing C99 against the Pascal from the '70s. The fact that some C features are present, does not make Pascal C, as the article suggests. Pascal remains a strong typed language, is still case insensitive, still has bounded arrays, still prevents "if (a=b)" mistakes and so on. And C has not become Pascal by taking Pascal features.

The fact that many extentions were introduced by Borland is no excuse. The Borland extentions are impemented by all Pascal compilers, Delphi, Virtual Pascal, Free Pascal and code between those compilers is interoperable. Even GNU Pascal, which does not implement the Borland dialect, has implemented the Borland extentions. It also needs to be said that many people who attribute extentions to Borland don't know their history, as many features in the "Borland" dialect originate from USCD-Pascal. It is a fact that the extentions have not been formalized in an ISO-standard, like it is the case for C. That is a valid comparison to make, and the article also needs to discuss features the extended Pascal ISO-standard.

However, the Pascal described in this article does not exist. It is not the Pascal people learnt at school and described in their textbooks. It is not the language that is being programmed today. It is an artificial language, and a valid comparison cannot ignore the modern Pascal in wide use today.

The POV you are describing here is your own. I didn't and don't have a problem with your assuming Dephi, but that should clearly be labeled "Delphi vs. C", not "Pascal vs. C". Borland does not describe their product as "Pascal" any longer, and for good reason.

Describing original Pascal as a language that "does not exist" is your own opinion, and a quite biased one at that. There are in fact several such implementations, see the Pascal page. What you are describing is language bigotry at it's worst. So you like your particular language dialect. That's fine. However, you feel the need to insult the original Pascal. If the existence of another Pascal dielect bothers you, that's your personal issue, not ours.

In any case, you have what you wanted. This page has turned into the "Delphi vs. C" page. So everyone is happy, right?

--Samiam95124 23:25, 2 March 2007 (UTC)

nl:Gebruiker:Danielm

I think it could be fair to consider Pascal features which are identical in all the popular Pascal compilers, without playing with command-line switches too much. You can't count something that is implemented differently. You can't count both Borland and ISO features if a popular compiler is unable to support both at the same time. (that is, with the same command line) Note: if you do this, then you have to say that modern Pascal is not defined by any standard. You might prefer to stick to the second ISO standard, so that you can say that Pascal is standardized. AlbertCahalan 07:17, 24 April 2006 (UTC)

Standardization of Pascal is definately a problem and the article should tell the truth in this regard. The second ISO standard has the problem that it is only a standard on paper and not a standard which is implemented by interoperable compilers. (GNU-Pascal is the only compiler that did implement it up to today.) This is because it is mutually incompatible with the actual standards (an ISO compiler cannot compile USCD, Turbo Pascal or Delphi code), so the industry couldn't make their compilers ISO-compatible without breaking all existing code.

If you want to talk about Pascal standardization, it is best to consider both the ISO standards as the industry standard, which is the language that developed through USCD, Turbo Pascal and Delphi (and is also implemented by Free Pascal, Virtual Pascal and many other compilers). nl:Gebruiker:Danielm

There are several errors in the statement above. First, several compilers implement the ISO standard, not just GNU (see the Pascal page for this). Second, the ISO standard came BEFORE Turbo/Delphi, so the issue is not that the ISO standard would break existing implementations, but rather that Borland chose to ignore the standard. This makes the last point irrelivant, since it is not the job of a standard to be changed to the point of incompatibility to adapt to later compilers that ignored the first standard. If a Borland standard were to exist, it would be its own separate standard.

The reason why Borland didn't create such a separate standard is clear. Borland is not compatible with itself from version to version, much less anyone else's language.

--Samiam95124 23:15, 2 March 2007 (UTC)

Indeed my POV. Lets separate POV from facts, facts first:

1. The ISO standard came *after* UCSD Pascal.
2. Language features like strings and units are a UCSD Pascal features. Runtime library procedures like fillchar are UCSD features too.
3. Therefore, the ISO standard ignored an exteremely influencial compiler.
4. Borland ignored the standard, but not UCSD Pascal. The Turbo dialect is remarkably backward compatible with the UCSD-Pascal dialect.
5. Think (on Macintosh platform) did not ignore the standard, but did not ignore UCSD-Pascal either.
6. I'm not aware of any breakage in the Borland dialect, with exception of the switch from Turbo Pascal -> Delphi
7. What article considers as "Pascal" is the Pascal from 1970.

Now the POV: It is not correct to compare Pascal from 1970 with modern C99. nl:Gebruiker:Danielm

Maybe it should be split into two articles? Something like "Historical Comparison" and "Modern Comparison"? Kleg 23:57, 14 June 2007 (UTC)

I'm not against this, but I don't think it is necessary; the article is already much better than before; the especially original "Blue Sky Pascal" section was really suggestive. There have been two main branches of the Pascal language, ISO and UCSD. People didn't program with the Pascal from 1970, but with compilers that did implement one of these branches.

To make the article more balanced this distinction needs to be made. I.e. recently the section about strings was adapted, and I support this change, but it isn't the complete story, and this where the original POV makes sense. Let's make a graph of the development of the Pascal language along with the dates of influencial compilers (actually I don't consider GNU an influencial compiler, but I list as it is the most notable representative of ISO Extended Pascal):

       Pascal
          |                  Pascal:       1970
         / \                 UCSD:         1977
        /   \                ISO:          1983
      UCSD  ISO              Turbo:        1984
      /  \  / \              Think:        1986
     /    \/   \             ISO Extended: 1990
    /   Think   \            Free Pascal:  1995
  Borland |    ISO Extended  Delphi:       1995
    |  Metrowerks \          GNU:          1989
    |     |       |          Metrowerks:   1994?

The current text about strings does justice to all compilers after about 1990 and for compilers from the UCSD branch long before. We would inform the reader badly if we said Pascal had just the character arrays of 1970, as in the original text. However, to inform the reader properly we cannot omit the information either that the string was there not right away, and most importantly, ISO Extended has a different syntax than UCSD. (I think this is where ISO failed, in 1990, the industry had already accepted the UCSD way as universal for a long time.)

Further I'd like the article to discuss the different modular programming approaches between C and Pascal, i.e. units versus header files.

nl:Gebruiker:Danielm

Couldn't agree more, well not much anyway. /HenkeB 13:55, 25 June 2007 (UTC)

I'm going to pass on indenting this yet again. The above is a complex work, but it is a complex work of fiction. The idea is to introduce the idea that UCSD branched off from "original" Pascal, then ISO occurred in completion with that, then Borland was based on the "alternative" branch of UCSD. Oh, I don't doubt that the authors believe it. However, it does not match any documentation available.

UCSD was created as an incompatible dialect of Pascal. It was incompatible due to several omissions, deliberate and otherwise, from Wirths 1973 Pascal, as documented by the Report. ISO simply standardizes the language of 1973 Pascal. Further, Borland is not compatible with UCSD either. In fact, UCSD implements several standard items like file buffer handling, and the get() and put() procedures, which Borland does not. So much for Borland being a "branch" of UCSD.

Lets make this simple. There isn't going to be a realistic discussion of this kind of thing as long as Borland/FreePascal users refuse to do even basic research into the history, language and standards of Pascal. Have you read the ISO standard? Have you read the 1973 Report from Wirth? I don't say this to be negative, its just that if you had read both, you would realize that ISO Pascal and Wirth's 1973 Pascal are the same language, just as you would realize that UCSD and borland are not.

—Preceding unsigned comment added by 66.28.253.185 (talk) 01:51, 17 October 2007 (UTC)

Let me also add this simple idea. The above discussion was obviously created by FreePascal people. If you spent HALF as much work as you do PUTTING DOWN the original Pascal language and the standard towards implementing the small differences between original Pascal and FreePascal into your compiler, this entire thing would be a non-issue. It's not even FreePascal's fight. It was a useless fight Borland started to "prove" they were superior by changing the original language around to a proprietary one of their own choosing.

GPC (GNU Pascal) followed the sensible course of making a compiler that was compatible both with Borland and with the original language as well, and in fact most of the differences aren't even in conflict. For example, get(), put() and file buffer access could be added to a Borland compatible compiler without any effect on the Borland compatibility of it.

The bottom line is that you are walking a thin line here. If you keep stating how STUPID the original Pascal language is, then why was it worthy of basing your wonderful FreePascal on? This is the real reason FreePascal folks have to "prove" that somehow the ISO 7185 standard is a bastard child. —Preceding unsigned comment added by 66.28.253.185 (talk) 19:46, 6 November 2007 (UTC)

[edit] Simple Types

The article states C accommodates different sizes and signed/unsigned modes for integers by using modifiers such as long, signed, unsigned, etc. The exact meaning of the resulting int type is machine-dependent. In Pascal, the same end is performed by declaring a "subrange" of integer

However, I recall that pascal had different 'integer' sizes: boolean, shortint, char, byte, integer, word (unsigned integer), longint and dword/cardinal (unsigned longint). These could be compiler and platform dependent, but all the pascal compilers I remember using (turbo/borland pascal, gpp, freepascal + several others) have supported those meaning they're de-facto standards and thus should be mentioned or alternatively the article renamed to Comparison of Pascal and C standards instead of the current name which implies more practical usage differences (in which case the image the article portrays of Pascal is horribly outdated). - G3, 13:25, 3 April 2006 (UTC)

Same discussion as above, the article discusses a Pascal that does not exist today, perhaps never did exist, as even early compilers introduced multiple integer types. nl:Gebruiker:Danielm

No, it goes to the same idea that this page no longer carries an accurate name. It should in fact be "Dephi vs. C", since it, and the above discussion is all about Dephi specific features (Pascal neither has nor needs "longint" type declarations). Further, characterising original Pascal as "nonexistent" because you don't like it is an insult, not a fact.

--Samiam95124 23:31, 2 March 2007 (UTC)

"type longint=-2147483648..2147483647" defined in the system unit is not against any Pascal language rule. Yes, I consider (which is my POV) it part of the language as the majority of Pascal code bases uses it. Show me a living code base in the original Pascal and we'll talk. nl:Gebruiker:Danielm

I think you misunderstand. Nobody is debating that Pascal extensions (like longint) can and have a right to exist. We are debating if the extensions of each and every implementation of Pascal should be germane on a page about the language Pascal. There is definately a place for discussions about longint per Delphi and C, but that page is "Delphi vs. C", and you are most welcome to write it, and link from this article to it. —Preceding unsigned comment added by 66.28.253.185 (talk) 20:01, 26 December 2007 (UTC)

[edit] C function pointers versus Pascal functional arguments

I wonder if it would be worth including a comparison between C function pointers and Pascal functional arguments. I believe this distinction had an important impact historically.

Pascal functional arguments carried their lexical context with them, which meant that nested functions could be passed as arguments to other functions. This had many advantages, but it also meant that extra data needed to be carried around, and in order to maintain a stack discipline and avoid garbage collection, it was necessary to prevent functional references from being stored in data structures or returned as values from functions.

Huh? Then don't use nested functions if you don't want to. Use pointers to regular functions. You can store references to functions in data structures in FPC/Delphi.

In C, on the other hand, since there were no nested functions, a function pointer just had to point to the start of the code, and required no extra information. This allowed function pointers to be stored in data structures and returned as values from other functions.

Huh? You can store a function pointer in a data structure in in FPC/Delphi.

The net result was that although C function pointers were, in a sense, less powerful than Pascal functional arguments, you could do more things with them. C function pointers were first class, while Pascal functional arguments were not.

This made some things possible in C programs that were difficult or impossible in Pascal programs. For example, a structure containing function pointers could be used somewhat like an Object in Object Oriented Programming.

Huh? In FPC/Delphi and other popular Pascal's you can also fake Object Orientation by using pointers to functions, and faking SELF too. Pointers to functions stored in a record act as the get/set methods. To simulate object orientation, all you need to do is declare a record data structure with function pointers, and pass SELF parameter into each function, which references the record. Since procedural code doesn't know anything about SELF, the record datastructure needs to be passed in to each function and it acts as self. Likewise, in C you'd have to do similar.

Unix kernel drivers could be stored in a table that contained pointers to the code for handling each type of device. Kleg 15:19, 2 September 2006 (UTC)

Sure, I belive your text above could more or less be pasted "as is" direcly into the article. I'm personally not fond of wording like "first class" however, better write it out, "possible to store and manipulate" or something like that.

Cheers /HenkeB 01:10, 3 September 2006 (UTC)

No, the text above should not be more or less pasted as is, as it is misleading and/or incorrect.

Hm... it also occurs to me that it may be worth mentioning that the boolean operators in Pascal don't short circuit, while the ones in C do. Well, I'll try and write up some additions if I get time, but I won't be insulted if someone else beats me to it. Kleg 17:20, 4 September 2006 (UTC)

Absolutely worth mentioning. /HenkeB 17:43, 5 September 2006 (UTC)

I guess the question revolves around whether this is meant to be a historical comparison or a modern comparison. If we include both gcc extensions to C (such as nested functions) and Delphi extensions to Pascal (such as function pointers) we will lose some historical context. If we compare historical versions of C (say, K&R or K&R 2) with historical versions of Pascal (such as the version described in Pascal User Manual and Report) we will have fans of both languages constantly pointing out that modern versions have more features. Kleg 18:58, 30 January 2007 (UTC)

That is fine. The alternative is to have this article trying to compare two continually moving targets. Why not open it up to C++ as well, since many versions of Pascal have object orientation? The bottom line is that there is clearly a official C and just as clearly an official Pascal, both came about at about the same time, both were standardized about the same time. If the purpose is to compare to "modern" [1] versions of the languages to each other, then this is fine, it just needs to be on its own page, such as "delphi vs. C" or whatever. [1] I placed "modern" in quotes because this term is often used as a negative connotations for Borlands language which is not compatible with Pascal (either the standard or Wirths original language specification). There are in fact several "modern" compilers that also implement original Pascal, GCC, IP and others. —Preceding unsigned comment added by 66.28.253.185 (talk) 19:56, 19 December 2007 (UTC)

[edit] Whether Article Should Exist?

I don't think it should exist. The two languages are at best loosely related, and one didn't really evolve from the other. This article explains an inexistent "bond". Siddharthagandhi 03:00, 11 November 2006 (UTC)

I wrote the original article, and I agree 100% with that. It is truly an apples and oranges comparision. It was done primarily in exchange for the removal of several deragatory comparisions that appeared in the Pascal language page.

Now this page, if it exists at all, should be "comparision of Delphi and C", since it covers the Delphi language, not Pascal.

--Samiam95124 22:58, 2 March 2007 (UTC)

I agree that comparing modern dialects of C and Delphi is not very useful, but a comparison of "Standard Pascal" with K&R or K&R 2 has historical value. C and Pascal were the main systems programming languages for many years. How the features they had at the time interacted with the needs of programmers at the time and the nature of the hardware they were using at the time had a noteworthy historical impact. Kleg 00:16, 6 March 2007 (UTC)

I agree, that was what I thought it was when I made my contributions — a comparison of Wirth's and Richie's original design aims. Quite soon some people started to claim that C = C99 (to be able to say that C has boolean typed variables and such) and that made me feel I was wasting my time. However, I certainly support the idea to make it into two separate articles, such as Pascal versus K&R C (1978, when C had become fairly stable) and Delphi/FreePascal versus C99/C++ (today) /HenkeB 09:02, 25 June 2007 (UTC)

I found this article to be interesting enough to read, but while the main outline of the article is fine, the comparing detail get's kind of 'fuzzy' in the text itself. I vote to remove this page unless this 'fuzzy' is taken out. (Lines run from C to Pascal without a real border, this makes it harder to read and get a conclusive feel for the differences.) Coen Leermakers 21:03, 6 March 2007 (UTC)

[edit] Type escapes

The C example doesn't make much sense:

int a;
float b;

a = (int) &b;

I suspect it was supposed to be:

int a;
float b;

a = *(int *) &b;

The former casts the pointer to b in a; it is not undefined behavior. The latter is undefined behavior, but does indeed on many machines store some of the bits of the float b into the int a.

I'm changing the article. — Derobert 17:29, 12 April 2007 (UTC)

I don't think that example demonstrates anything of use. Essentially, the final statement can be syntactically simplified to:

a = (int)b;

And an optimizing compiler might do that anyway. Perhaps it would make more sense to illustrate it like:

int *a;
float *b;

a = (int *)b;

Which seems more useful (rather than creating a pointer from a primitive just to change its type and then dereferencing it back to a primitive). As a side note, I think you used 'former' and 'latter' inaccurately, as reading your post doesn't make any sense based upon the action you took.—Kbolino 05:21, 13 April 2007 (UTC)

[edit] LL(1) parseability

This is something I'm not so sure on, but I seem to recall reading or hearing that Pascal is LL(1) and C is not. If this is true, this is pretty significant and deserves mention in the "syntax" section, perhaps in the "Implementation" part of that. –Andyluciano 17:57, 10 July 2007 (UTC)

It's an "overly obscure" point, but I would back your including it, if you so choose to do it. Please do some research beforehand.

I have created both Pascal and C front ends, I'll vouch for the irregular syntax of C. C is certainly parseable, but relies quite a bit on context dependencies. Its not an error. You can create a language that is regular to the point of being parsable without considering the type of declared symbols in the language. In fact, there are virtually no languages that meet this high bar. Pascal fails in only one point, the fact that assignment (a := n) needs the context of the symbol to parse it ("a" could be a function or even a function result). The C language was created with the idea that its notation should be as short as possible, including use of the declarative information to guide syntax.

I don't personally use YACC or similar parser generators, so for me a C parser was fairly straightforward to create using straight code. I have heard that using parser generators with C is either impossible or requires a lot of modification or special cases to be used with the final generated code.

In any case, the difficulties parsing C are difficulties for the implementor, not the user, which is perhaps one reason not to mention it here, since this article is primarily about users. The only net impact for the user is that errors tend to be less recoverable in C than Pascal (that is, syntax errors tend to cause the compiler to fall out of sync with the source code), resulting in the rule that "all errors after the first should be ignored". —Preceding unsigned comment added by 66.28.253.185 (talk) 19:53, 26 December 2007 (UTC)

[edit] Working on Replacement

The top of the current page does say that it needs help from an expert. Being one, I decided to start the page. You can access it at User:PGSONIC/Pascal and C. Feel free to add or remove information (but I will be editing always). When I feel the page has enough, this page will be replaced. - PGSONIC 20:12, 22 July 2007 (UTC) (fixed mistake PGSONIC 20:15, 22 July 2007 (UTC))

I don't know why you feel that the page needs to be replacing,

but a simple look at your page shows serious errors:

PROGRAM X; VAR

   A : PACKED ARRAY[1..5] OF CHAR;
   B : PACKED ARRAY[1..6] OF CHAR;

BEGIN

   A := 'Hello';
   B := 'Planet';
   IF A <> B THEN
        B := A;

END.

The above is not a valid Pascal program. A and B are not comparable, the are not in fact compatible types in every known implementation of Pascal, including Borland. This program will not compile, which you would know if you had actually tried it.

Do you want to rethink your story about being a Pascal "expert" (as you claim above)?

The steam coming out of your ears seems to have blurred your vision. Note that he stated "...the following program is invalid" Chris Burrows (talk) 23:18, 26 December 2007 (UTC)

[edit] Semicolon use

1. ad semicolon - transforming C expression into statement. i believe it is misleading. true. but not generally true. see

if(0) { } else { }

2. ad semicolon use - i really hate unstructured writing, which involves lot of parsing. it is not the best but i feel whole page should be made similar. —Preceding unsigned comment added by 84.16.123.194 (talk) 17:03, 25 February 2008 (UTC)

[edit] Is ; statement?

I have read it is statement in Pascal. But if it was a statement then it would be allowed between if and else, *righ before* else. Can someone clarify this? 84.16.123.194 (talk) 17:31, 25 February 2008 (UTC)

"is" is not statement. It is operator like "+" or "and". —Preceding unsigned comment added by 217.168.74.9 (talk) 14:56, 23 May 2008 (UTC)