Talk:Comparison of Pascal and C

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)

"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)

Good, although it is unfortunate that the page has to continually bear warnings. The page accomplished its original goal, which was to move C vs. Pascal arguments OFF the respective Pascal and C language pages. In fact, this is a model for how to handle all such language issues. I wholeheartly support the goal of creating subpages to compare specific dialects of each language. — Preceding unsigned comment added by 148.87.19.210 (talk) 00:39, 9 November 2013 (UTC)

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)

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

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.

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.

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.

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)

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 comparison 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 comparison. 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)

I don't see the point why this page exists in its current form.

It compares some old, long obsolete standards. No compiler currently supports those standards without ANY extensions. Particularly, Pascal as described here is dead. Virtually all modern compilers support Object Pascal, which is to Pascal what C++ is to C. Not to mention that most C compilers are actually C++ compilers with C-compatibility mode.

C is much better standardised than Pascal. That is, C compilers are more standard complying than Pascal compilers. Some compilers, like Oxygene, are so different from standard Pascal that they shouldn't deserve the name Pascal at all, despite being marketed as such (no one claims that Java is C, right?)

When one wants the "one true Pascal", then picking up some very old standard might be good, but it has no real-world value, as it is very obsolete and by no means representative of currently used Pascal compilers.--Azarien (talk) 22:26, 20 February 2010 (UTC)

a) Pascal and C Programming is not limited to developing Windows and Linux software. Pascal and C compilers available for embedded programming e.g. Keil, IAR, MikroElektronica etc., handheld devices e.g. PocketStudio etc. etc. tend to have very different extensions but still have the same core. If you are aware of the minimal feature set that you can reasonably expect to be consistent and what are inconsistent platform-specific extensions then there is less of a surprise and more ability to reuse generic code when you have to switch to a different compiler.

b) Most Pascal compilers and C / C++ implement languages that are based on supersets of the original. Current implementations still retain the language design flaws that were present in the origin language specifications. Programmers aware of these comparative flaws are in a better position to assess the choice of language for a particular task. Rather than redefining Pascal, Wirth addressed Pascal's flaws in Modula-2 in the early 1980's and again in Oberon in the 1990's.Chris Burrows (talk) 00:15, 21 February 2010 (UTC)

I am afraid, Chris, Wikipedia is no place for such justifications. Wikipedia is not a publisher of original thought, hence either cite your allegations or we may consider it nonexistent. In addition, Azarien has raised a valid concern: The factual accuracy of this article is indeed disputed: This article compares two very old versions of the language. This article primarily misleads a reader who wishes to learn more about the differences of the language by giving him or her invalid information. Bringing it up to date must be a primary concern. Fleet Command (talk) 05:32, 21 February 2010 (UTC)

Standards conformance statements for the IAR C compiler can be found at http://www.iar.com/website1/1.0.1.0/466/1/ and the Keil compiler at http://www.keil.com/support/man/docs/armccref/armccref_Cheifhbg.htm.

A reader who wishes to learn more about the differences between the minimal implementation of Pascal documented here and one proprietary extended version in common use today should refer to Comparison_of_Pascal_and_Delphi

Wirth's work is listed in the Further Reading section of the article: Niklaus Wirth: Recollections about the Development of Pascal. 333-342, ACM SIGPLAN Notices, Volume 28, Issue 3, March 1993.Chris Burrows (talk) 12:37, 21 February 2010 (UTC)

Thanks for the useful sources, Chris. However, they do not cite your allegations which you used to justify the articles lack of factual accuracy (i.e being outdated). Nonetheless, this article is not going anywhere: Lack of up-to-date info is not a problem that is likely to warrant the deletion of an article. Maybe in the near future, I can spare more time and attend to this issue. Fleet Command (talk) 13:27, 21 February 2010 (UTC)

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)

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)

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)

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)

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.

I would consider this one of the fundamental differences. In Pascal expressions are different from statements. That is why there are functions and procedures. A function call is an expression and a precedure call is a statement. In C every expression is a statement (but not the other way around). Procedures are simply functions that don't return anything (void). Function and procedure calls are both expressions and can be used as statements. Assignments are statements in Pascal and expressions in C that can be used as statements.

The other major differences are the way types are constructed in variable declaraions and the way arrays are handled. Everything else is syntactic sugar to me. You can do the same things with different syntax and there are differences in the availeable operators. The operators evolved over time to a practical set (I still miss the with statement from Pascal). Sconden (talk) 18:33, 6 October 2010 (UTC)

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)

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)

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)

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)

It's not about putting down but about NPOV. "Pascal" includes the direct derivatives too, and having this whole article (save one little paragraph) about the standard dialect is a bit doubtfull from a NPOV view.

Aside from that, I do like the article though. It is fairly detailed and reasonable, and states the fundamental differences good enough. But I'd like a bit more of a warning paragraph (iow something that shows up in the index) about the ISO vs Borland division of Pascal and the limitations of the comparison near the top, clearly stating that the Borland dialects are a different story, instead of a minor, easily overlooked paragraph at the end. And maybe a hint here and there that compiler extensions fix some of the defects (as they often do, even in the non-Borland dialects).

Keep in mind that we get the ISO propaganda bounced back to us as much as you get the Borland view and differences.

As far as incorporating iso standard features goes: Florian already stated that patches that fix ISO functionality were welcome in the 1997-1998 timeframe, and that has been reiterated several times (in e.g. comp.lang.pascal.*) since. There have been a number of patches (and even major work) from Apple Pascal people, non of which were particularly interested in the standards. The number of other patches regarding ISO compliance are exactly 'zero.

88.159.74.100 (talk) 14:19, 29 July 2009 (UTC) (Marco)

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)

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)

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)

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)

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)

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)

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)

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)

No, ";" is not a statement. It is a statement separator. Thus, in "if x then ;", semicolon separates the if statement from the next statement. It happens to also add a null statement as the controlled statement of "then", which is perfectly legal. Thus "if x then ; else ..." is not a legal statement because the next statement after the if is "else ...", which is not a legal statement.

I don't know why folks have a lot of trouble with this, it matches English language use and makes sense in general. You say "I made lunch AND THEN I cleaned the room AND THEN I slept", thus "I made lunch; I cleaned the room; I slept". Not the best usage but clear of intent. Contrast this with the idea of other languages that always require a "terminator" such as semicolon. This would be like saying "I made lunch AND". And what?

Source

A source that might be useful to cite is http://portal.acm.org/citation.cfm?id=14947.14950&coll=GUIDE&dl=GUIDE&CFID=606445&CFTOKEN=44901229 —Preceding unsigned comment added by 137.222.107.22 (talk) 15:32, 9 November 2008 (UTC)

Good suggestion. Done. Chris Burrows (talk) 22:52, 9 November 2008 (UTC)

Subranges, promotion

I'm not sure what this section is trying to say, so I'm not sure how to fix it. Was this section hacked at some long distant time?

Is there a "BYTE" type in original Pascal? Does original Pascal define that an integer must be at least 16 bits?

Every C compiler always promotes the subrange (char) of integer to integer. This makes C code "inefficient" on 8 bit platforms. A highly optimizing C compiler can reduce, but not eliminate, the effect of this under standard C rules.

If not 8 bit, What other "subrange" could this section be talking about that could possibly make C efficient? —Preceding unsigned comment added by 203.206.162.148 (talk) 04:36, 9 December 2009 (UTC)

Still broken. "In C, there are defined rules as to how to promote different types of integers, typically with the resultant type of an operation between two integers having a precision that is greater than or equal to the precisions of the operands.".

In C, typically the resultant type of an operation between two integers has a precision that is equal to that of the two operands. This normally leads to inefficient code, since you have to cast the operands to the higher precision before the operation. — Preceding unsigned comment added by 203.206.162.148 (talk) 07:52, 30 November 2011 (UTC)

Linking, Epilogue

A fundamental difference between Original C and Original Pascal is that Original Pascal did not define or envisage linking of external source or objects or libraries. Niklaus Wirth addressed this in his next language (Modula), and compilers addressed it in various different ways. There was considerable debate about this aspect of language design at the time.

C, "a small language of only 32 keywords" is a null language without the C library, which was the system library, which was the operating system. (The POSIX definition still includes a complete definition of the "C" library). This means you can implement C without implementing the library, you can replace the library and you have explicit control of which parts of the library you wish to use or implement. This made C particularly suitable for situations where you do not have the library, or were you do not wish to use the library: in particular, for writing OS or parts of an OS or OS drivers. By default, all C functions are public, that is, exposed for external linking. And the standard way to write C programs was a series of independent source objects, which were compiled, then linked in the same way the System Library was linked. However, the separate objects and the standard linking interface each impose a fundamental limit on an optimising compiler.

Wirt consciously adopted a different approach with Pascal. The language definition already include Read and Write. You don't need an external library to write programs. By definition, all Pascal functions are private, and there was no way to link in external source code.

This made for unwieldy programs, but removed the inefficiency of the linking interface and the separate objects.

The need to include functions like Read and Write meant that every compiler had to include the library: this was balanced by the fact that the language itself was explicitly designed to make it easy to write a small, efficient, correct compiler.

Since Pascal was explicitly designed to make it easy to write a small efficient compiler, it was also easy to write a correct optimising compiler, something that was very difficult in C: (hence the long standing advice that if you wanted your C program to be correct, you should compile with optimisations turned off).

The short term result was that Pascal Compilers generated small, fast, correct programs, but were unsuitable for system programming. C was more suitable for system programming, but C compilers generated applications that were small and fast only when compared to Lisp, not when compared to FORTRAN or Pascal.

The long term result is that C is used much more widely than Pascal, but the code is still large by default.

The way to get small, fast C code is the same way they got small fast Pascal code: put all of your code into a single file, declare all of your functions as static (ie local, private), and avoid using (external) library functions. Back in the day, programmers used .INC and .DEF files and included code in .H files. Embedded C compilers and linkers now have non-standard language extensions to help you do this, like -fWhole-Program in GCC.

Note, writing small programs and avoiding library functions was reasonable for the OS and for drivers: most of the library is unsafe and isn't relevant anyway in that situation.

The point of this is not to compare executables from Pascal and C (who cares?) The point is there was an original design decision (stand-alone program vs linked objects), which had front-end and back-end effects. —Preceding unsigned comment added by 203.206.162.148 (talk) 05:44, 9 December 2009 (UTC)

Strings in Pascal

The article asserts that Pascal does not have a dedicated string type. This statement, however, is false: I have been a recreational Pascal programmer since 1994 and pascal always had a dedicated string type which was not null-terminated and could safely contain null character in the middle, like this:

var
  somestring: string;

begin
  somestring:='Wikipedia,' +
              #0 +      //Null character
              'The Free Encyclopedia';
  writeln (somestring); //Result: Wikipedia, The Free Encyclopedia
end

I have as many as a ten reliable sources in written books and electronic documentation for this assertion of mine. But before I re-write the String section, I'd like to hear the explanation of the one who has made this seemingly-untrue assertion without citing a reliable source. Fleet Command (talk) 19:10, 3 February 2010 (UTC)

http://standardpascal.org/The_Programming_Language_Pascal_1973.pdf

In which you will see "strings ... are ... packed array[1..n] of char"

That is, there are strings, but no string type.

Wirth was the author of Pascal, and that paper is definitive, and it was followed in 1974 by the 'user manual and report'.

This article is about a language that was designed in the late 60's, early 70's. The fact that the language was designed without a string type is an interesting and important point, precisely because string types are important enough that implementations added them (formalised 20 years later in the 1990 ISO standard). Pascal and C were part of the last generation of languages to be designed without string types. It was already known as a limitation of FORTRAN, and had been corrected in BASIC and avoided in COBOL. —Preceding unsigned comment added by 203.206.162.148 (talk) 03:03, 8 February 2010 (UTC)

First: Your link is not working. Let's see if I can get it through Google Cache or Web Archive.

Second: Although there are no restriction on inclusion of ancient history in articles in Wikipedia, history must not be presented as facts. Assuming that what you say is correct, it means that the factual accuracy of this section of this article is compromised and this section must be either re-written or deleted.

For now, I am tagging this article as out of date. I'll see if I fix it later. Fleet Command (talk) 08:50, 8 February 2010 (UTC)

Good God! Have you read any of the article? Or this talk section? Go back and do it again!

I did not write this article. The meaning and intent of this article are clear. And you are going to 'fix' it?

I note that the link provided is still working.203.206.162.148 (talk) 00:40, 17 February 2010 (UTC)

First, the link provided is just now working. It wasn't working back then. I've downloaded it but since it cannot be searched, I have trouble finding your quotation.

Second, yes, I have read this article and every paragraph of it is outdated by at least 20 years. I repeat, 20 years. Such factual inaccuracy is in consistent with Wikipedia policies. In addition it lacks citations from reliable sources; another defiance of Wikipedia policies. Reading the article again won't solve any of this. In case of string, your source is written on July 1973, 37 years ago.

Third, no, I probably have no time in my life. I am a busy person. But I also don't sit around for Wikipedia readers to come to this article, read factually inaccurate stuff and receive misinformation. So I do the best I could do: I tag it. Fleet Command (talk) 11:37, 17 February 2010 (UTC)

Read the article again and note in particular: "What is documented here is the Pascal of Niklaus Wirth, as standardized as ISO 7185 in 1982." There is a later standard dated 1990 but there was no change to the definition of strings. There are and have been so many incompatible different extensions to Pascal that any attempt to encompass them here would make the entire article unmanageable. You can get a copy of the Standard from the reference on the Pascal (programming language) page. Your notion of a string type indicates that you may have been misled by references to non-Standard versions of Pascal.

Global tags are particularly unhelpful. Please identify the weasel words.Chris Burrows (talk) 12:32, 17 February 2010 (UTC)

"What is documented here is the Pascal of Niklaus Wirth" and is therefore old and factually inaccurate. Please update it to reflect the facts, regardless of whether the facts are consistent with this aged standard or not.

Just because it is old does not make it factually inaccurate. There were only minimal changes made when the ISO standard was produced. There is no later revision since 1990. Do not make the mistake of confusing the definition of Pascal with various implementations of Pascal. As it states in the preface of the Pascal User Manual and Report: "An implementor should regard the task of recognising Standard Pascal as the basic requirement of his system .... Of course, individual implementations may provide additional facilities which however should be clearly labelled as extensions".

A Pascal 'string' type is an extension e.g. Delphi (a.k.a Object Pascal) has some half-a-dozen built-in 'string types'. It would be factually accurate to state that such a string type exists in an article that e.g. compares Turbo Pascal with Microsoft C, or Embarcadero Delphi with Microsoft Visual C++. It is incorrect to claim that Standard Pascal has a string type.Chris Burrows (talk) 00:50, 18 February 2010 (UTC)

As for weasel words, you cannot fail to see them: They are all over the place.

Here is a few examples:

The article starts with:

"The computer programming languages C and Pascal are often compared to each other, sometimes heatedly, probably because the languages have similar times of origin, influences, and purposes, and so represent two philosophical approaches to a similar need."

I have underlined the weasel words.

• often compared to: By whom? If you don't know by whom, then how do you know they are compared? (Cite your source please.)
• sometimes heatedly: Blatant weasel word: Since no source is cited for it, it is obvious that this phrase is meant to give an illusion of notability.
• probably: Speculations and probabilities are not allowed in Wikipedia. Either you know it as a fact (i.e. you have a source for it) or otherwise the phrase is an attempt to fake notability.

As you see, the global tags are very useful. Unless you intentionally turn a blind eye to weasel words, you'll see them all over the article. For more information, visit WP:WEASEL and WP:Words to avoid. Fleet Command (talk) 22:54, 17 February 2010 (UTC)

These examples have now been removed. Weasel words are subjective by definition. What may seem to be weasel words to you might not appear so to others. Remove any that you are aware of and I'll recheck to ensure that you haven't compromised the factual accuracy of the article.Chris Burrows (talk) 00:50, 18 February 2010 (UTC)

FIRST: Please be careful! You just added more weasel words. Can be usefully, without source, is another weasel word. Why do you bother writing such a thing after all? Useful or not, often compared or not, good or bad and for what so ever the reason, this article is comparing them. You don't need an alibi for something that is not illegal!

SECOND: There is quite a soild guideline at WP:WEASEL and it is quite obvious what is weasel and what is not. For the slight problem we can always talk. However, there is one way of addressing weasel words: Source! You use seemingly-weasel words but then you give citation from a trustworthy source. That's not a weasel word. Fleet Command (talk) 10:01, 18 February 2010 (UTC)

Weasel Words to you, and yet you have no compunction about doing exactly what was described in that sentence: "comparing" two languages (Pascal and the languages you are familier with) "Sometimes heatedly", I can't measure your temperature, but I note that you have changed your stated arguments and your stated intentions in the course of the discussion: in a normal discussion, this indicates that emotions have taken over from rational discussion. In this thread, your use of ALL CAPS indicates the same thing. These are not Weasel Words: this is a direct description of what is happening right here.

Any way, emotions aside, you've indicated now that you don't have time to read and check the article. Go in peace. —Preceding unsigned comment added by 203.206.162.148 (talk) 23:46, 3 March 2010 (UTC)

Thanks, that was the best review of my work I think I have ever got. It made me laugh. I shall now Weasel on out of here. — Preceding unsigned comment added by 148.87.19.210 (talk) 01:00, 9 November 2013 (UTC)

Ridiculously out-dated Pascal in the article

Anyone that whishes to compare C to old historical versions of Pascal which are no longer used by anyone, please create a new page: Comparison of C and historical Pascal.

Noone uses that old Pascal anymore, therefore it is ridiculous to say that it is "Pascal". Pascal is the modern implementation in Free Pascal and Delphi which are the de-facto standard. --Felipe Monteiro de Carvalho (talk) 10:47, 6 November 2010 (UTC)

You are one of the main Free Pascal developers, right? If so, instead of attempting to rewrite history you should consider renaming 'Free Pascal' to 'Free Object Pascal' or 'Free Delphi' as that would be a more accurate title. If you want to write an article about (Borland's dialect of) 'Object Pascal' it would ridiculous to compare it with C. C++ maybe? Chris Burrows (talk) 11:11, 7 November 2010 (UTC)

Well, it might be correct to say a "comparision of old historical C to old historical versions of Pascal". The problem is that C has evolved quite a bit too. — Preceding unsigned comment added by 148.87.19.210 (talk) 01:02, 9 November 2013 (UTC)

WEB and C

Some of the features of WEB allow you to use some C-like features in Pascal programs. Some of these features are as follows:

• Preprocessor macros
• Conditional compilation (implemented using preprocessor macros)
• Hexadecimal numbers and octal numbers
• Character constants converted to the ASCII number of that character
• Constant expressions in place of numbers

Not all features of C can be used in WEB. There is still no bitwise operations. --zzo38(✉) 06:11, 7 November 2010 (UTC)

Strings in C

The "strings" section directly implies that C does not have any support or definition for strings at all, yet when revising the C99 standard draft (ISO/IEC 9899:TC3, n1256.pdf) section 7.1.1 Definitions of terms:

A string is a contiguous sequence of characters terminated by and including the first null character. The term multibyte string is sometimes used instead to emphasize special processing given to multibyte characters contained in the string or to avoid confusion with a wide string. A pointer to a string is a pointer to its initial (lowest addressed) character. The length of a string is the number of bytes preceding the null character and the value of a string is the sequence of the values of the contained characters, in order.

I suggest this statement be reworded to state that C does not have a string type, however it does have an official definition for "string" as a representation. — Preceding unsigned comment added by Plebbeh (talk • contribs) 07:48, 19 December 2010 (UTC)

Er, were you talking about:

C does not have built-in string or array assignment, so the string is not actually being transferred to p, but rather p is being made to point to the constant string in memory.

Otherwise I don't see anything about C having or not having support for strings. Also, C99 is a later version of C, one that came out in 1999, quite a ways after original C.

Copyvio

The section Implementation issues is a copyvio from Let's Build a Compiler from 1988 (search for "When Niklaus Wirth designed Pascal"). It was added on May 30 2007. Caesar (talk) 21:28, 19 June 2011 (UTC)

Pass by Reference in C

C does not have pass by reference mechanism. Passing parameters through pointers is still pass by value. So that needs to be fixed in the article. Akhwaja (talk) 00:54, 30 September 2011 (UTC)

I don't see anywhere where it says that it does. — Preceding unsigned comment added by 148.87.19.210 (talk) 01:10, 9 November 2013 (UTC)

Arrays by reference

The article should mention the significant exception in C: Arrays are effectively passed by reference as they are effectively always pointers. I.e. arrays, unlike structs and simple variables, are not copied when transfered in and out of functions. One should also mention that arrays in function arguments are unsized and it is therefore customary to add a separate size argument to get around this. 78.82.155.234 (talk) 17:33, 29 March 2020 (UTC)

Notability

Can anyone show that this subject meets WP:GNG? ButOnMethItIs (talk) 10:57, 17 October 2011 (UTC)

How do you do see if a variable is in a set, ie in pascal for integer i you can do if i IN [1,5,9,12] then DoSomething() — Preceding unsigned comment added by 118.92.183.141 (talk) 01:02, 29 September 2013 (UTC)

observation about string methods

I restored the line "The Pascal method is arguably faster, because no interpretation takes place, but the C method is highly extensible.", because the only justification for removing it was that the remover didn't personally know that it was true. It should be referenced. Unfortunately, when I look for references, all I find is observations that sprintf, and other methods which use inline interpretation of format strings, are hopelesslly slow, not a comparison, in the same languge, of precompiled and interpreted format strings. Such a comparison must now exist, because there are now C compilers which will do compiled interpretation of sprintf arguments.

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Comparison of Pascal and C. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20050314152247/http://www.cs.inf.ethz.ch/~wirth/books/Pascal/ to http://www.cs.inf.ethz.ch/~wirth/books/Pascal/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 16:35, 11 August 2017 (UTC)

Array initialization

The remark "Pascal has neither array initialization (outside of the case of strings) nor a means of determining arbitrary array sizes at compile time" is only halfway true.

Arbitray array size at compile time ar unknown, but it is perfectly possible to initialize an array at compile time, in my opinion.

My Pascal compiler does not object to constructs like:

data: array[0..9] of integer = (10,20,30,40,50,60,71,80,90,91);

. Am I right, or do I miss some point?

--Bloksma (talk) 08:40, 26 October 2018 (UTC)

It is a 'non-standard language extension' in your Pascal compiler and should be identified as such in your compiler documentation. If you are 100% sure that you will only ever want to run your code on the system that it currently runs on then you don't need to worry about it. However, the more non-standard features that you use the more problems you will face if you ever want to get your code running on a different system. Chris Burrows (talk) 22:06, 26 October 2018 (UTC)

Mature version?

In the lede : "The reason is that these versions both represent the mature version of the language,".

Pascal in 1982 and C in 1989 were the mature versions of each language??? Based on what? Also, C in this description is almost twice as old in 1989 as Pascal was in 1982. Yet even for C, in 1989, it seems it still had not yet reached its mature age. This kind of feels like comparing the skill level of an 8 year old to a 16 year old. And why are we comparing outdated versions of each language that nobody uses (this coming from someone who still uses an assembler from the early-mid 1990s, A386, and writes modern programs as if it still needs to fit within 640K memory)? In Pascal's case, nobody has ever used that ""standard"". — al-Shimoni (talk) 01:14, 12 April 2024 (UTC)