![]() |
|
1
17th May 02:37
External User
Posts: 1
|
I'll take the cases one by one. The quoted article
is from my site: http://www.moorecad.com/standardpascal/ansiiso.faq (1) This is absolutely incompatible with J&W (AKA 1972 revised Pascal). (2) The standard extended the original J&W in this case. Fully compatible. (3) Incompatible. (4) Compatible. J&W 1972 left these rules up to the implementation. An implementation of ISO 7185 would be compatible with J&W 1972 for this case. (5) Compatible. The key, again, is "implementation defined". An ISO 7185 implementation would be able to run J&W programs that didn't rely on short labels, as J&W says not to. (6) Compatible. Again, implementation defined. (7) Incompatible, because a valid J&W program, using a for loop variable defined in a different block, would not compile, and it wasn't labeled as "implementation defined". To summarize the rules that would PREVENT a valid J&W 1972 program from running on a ISO 7185 implementation: 1. Use of procedure/function parameters without also declaring their parameters. 2. Passing standard system procedures and functions as procedure/function parameters. 3. Use of for loop variables from a different block. These are hardly common cases, and they are quite easy to change. Further, Wirth himself requested the procedure/function parameter change. Finally, J&W, in the third and forth edition, fully incorporated these changes. Certainly it has become common to spread the myth that J&W 1972 is incompatible with ISO 7185, but the facts say different. The key is being more interested in the facts than the retoric. If you are trying to "prove" that ISO 7185 is incompatible with J&W, you can find examples of programs that won't compile under ISO 7185 Pascal. But if you look at J&W's rules of 1972, you will find that the same programs were disallowed under that standard as well, since they use things like gotos to nested structures and other constructs that J&W 1972 fully allows implementations to reject (which is the meaning of implementation defined). Scott A. Moore |
|
|
SPONSORED LINKS BY GOOGLE |
|
4
17th May 02:37
External User
Posts: 1
|
Just one slight correction. I never said the above.
-- Samiam is Scott A. Moore Personal web site: http:/www.moorecad.com/scott My electronics engineering consulting site: http://www.moorecad.com ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal Classic Basic Games web site: http://www.moorecad.com/classicbasic The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal compiler system: http://www.moorecad.com/ippas Good does not always win. But good is more patient. |
|
|
SPONSORED LINKS BY GOOGLE |
|
5
20th August 16:27
External User
Posts: 1
|
The standard clarifies the rules of J&W 1972. A implementation
that used ISO 7185 would qualify as an implementation of J&W 1972. Note that you must use "J&W 1972", because: 1. In 1969 the language Pascal was created. 2. In J&W 1972 (the "report", language was revised. See my web site, it has that original copy online. 3. In 1983, J&W was revised again to meet the ISO 7185 standard. The language you would call Wirth's standard Pascal, is actually the langauge as of 1972, as reported by J&W. Much as with the ANSI C standard, the purpose of ISO 7185 was not to change the Pascal language, but to clarify it. Because a program (as has been seen) could easily have been written to be dependent on the CDC 6000 version of Pascal, it should be generally agreed that the test of if a program runs or does not run from the original CDC 6000 implementation to other implementations is not a test of the language Pascal, otherwise all Pascal implementations would be considered different. So the question "does an implementation qualify as Pascal" must be performed by comparing the rules of J&W 1972 to the rules of ISO 7185. The question "is ISO 7185 Pascal different from J&W 1972 Pascal" can only be answered by critically examining if, and how, it would be possible to write a program in J&W 1972 Pascal that was valid, conformed to all stated machine dependent rules (as again, stated by J&W 1972 Pascal), but would not also be processed correctly by ISO 7185 Pascal. First, its clear that you made up your mind about this subject long before reading this thread. That changes the "discussion" to an argument, or at least a rebuttal. I have answered the question "is ISO 7185 Pascal" the same as Wirth's Pascal, so my part is done. Feel free to use this space as you desire. -- Samiam is Scott A. Moore Personal web site: http:/www.moorecad.com/scott My electronics engineering consulting site: http://www.moorecad.com ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal Classic Basic Games web site: http://www.moorecad.com/classicbasic The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal compiler system: http://www.moorecad.com/ippas Good does not always win. But good is more patient. |
|
|
9
20th August 16:28
External User
Posts: 1
|
If that's your main grief, please check the standard again.
5.1 says: : A processor complying with the requirements of this International : Standard shall [...] : : f) treat each violation that is designated an error in at least one : of the following ways : : 1) there shall be a statement in an accompanying document that the : error is not reported, and a note referencing each such statement : shall appear in a separate section of the accompanying document; : : 2) the processor shall report the error or the possibility of the : error during preparation of the program for execution and in the : event of such a report shall be able to continue further processing : and shall be able to refuse execution of the program-block; : : 3) the processor shall report the error during execution of the : program; and if an error is reported during execution of the : program, the processor shall terminate execution; if an error occurs : within a statement, the execution of that statement shall not be : completed; : : g) be accompanied by a document that separately describes any : features accepted by the processor that are prohibited or not : specified in clause 6: such extensions shall be described as being : `extensions to Pascal as specified by ISO/IEC 7185'; : : h) be able to process, in a manner similar to that specified for : errors, any use of any such extension; So, it is possible for a processor to accept extensions, but then it must at least document them twice, first as being extensions, and then as being not reported (or document them once, and at allow to reject them at compile-time or run-time). You may thing that's still to liberal, but in reality what more could you expect? If this wasn't allowed, compiler makers would probably still make extensions, just they couldn't say "conforms to ISO 7185 with the following extensions ... and those extensions are not reported", instead they would say something like "... implements the language described in ISO 7185 plus the following extensions". It wouldn't make a practical difference. BTW, the standard doesn't enforce portability (as you seem to imply above). Even a perfectly conforming program could be unportable (cf. 5.2 note 2). The standard requires documentation of implementation-defined features (here: MaxInt) (5.1 d). So you need to consult the documentation of the processor and evaluate your program with respect to it if you want to ensure portability (or check your program against the standard). This goes for extensions just as well as for implementation-defined features. Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E) Pascal code, BP CRT bugfix: http://fjf.gnu.de/programs.html Free GNU Pascal Compiler: http://www.gnu-pascal.de/ |
|
|
10
20th August 16:28
External User
Posts: 1
|
The J&W 1972 Report is available here, a .PDF of the original:
http://www.moorecad.com/standardpascal/documents.html You're welcome. Sure. Of course, by that definition the CDC 6000 implementation, and all other implementations are not original, since Wirth revised the language in 1972, as covered by the Report, which you have access to above. Thats simply not true. The Report, and all other Wirth documents not only do NOT forbid extensions, but the J&W gives a whole chapter dedicated to the extensions present in CDC 6000 Pascal ! I do understand that this is a common myth spread concerning Pascal (mostly by Borland advocates who seem to want to "prove" that other Pascal implementations are as incompatible with original Pascal as Borland is). However, telling the same myth over and over does not make it true, just redundant. The standard allows for extensions, just as Wirth's original Pascal did. The ISO 7185 standard goes farther by asking that complying processors implement an option flag that rejects non-standard constructs so that programmers can create absolutely compliant programs if that is desired. You asked for two things, above, so I'll address them separately. First, for the standard to NOT ALLOW extensions is an absurd requirement. Wirth hallways intended that extensions be present in the language, and specifically discussed what should and what should not be in the standard vs. discussed as a local processor extension. Basically, Wirth was saying that some features were inherently machine dependent and should NOT be standardized. This is all available if you read J&W. Now as for "extensions should be in the standard", Wirth, again, addressed that issue in J&W, and many times thereafter, that some extensions or machine dependent features should NOT be standardized. If you read J&W, the CDC 6000 implementation you will find a list of them (for one sample machine). Finally, no language is static, and Wirth never intended the language to be set in concrete, never to be extended ever again. For your requirement that "If extensions are necessary they should be defined and included in the standard" presumes that the makers of the standard knew the future, and could anticipate all needs forever. The language Pascal was created by Wirth in 1969. The standard was created in 1982. We are talking about a language almost 35 YEARS OLD ! Thank you for your interest in the standard. |
|
|
|