A pragmatic discussion about Pascal standards and dialects. By Marco van de Voort. Note: this is a draft. I welcome feedback. Since the original revisions, ISO related discussions are more attached to historical codebases and books, and less about the Apple targets. Since the original concept of this faq, the Mac users mostly have moved on to GPC, and after its demise to FPC. Most remaining ISO use seems to be historic codebases related to books, quite often in the compiler and (bytecode) interpreters corner. Q: Is this the anti Ansi/ISO faq? A: No. Q: Are you against standards? A: No. As long as reasonably Open, I'm generally in favour, for the obvious reasons. Q: Are you against Pascal standards? A: In general: no. They adhere to the "Open" requirement above, except that their availability seems to require a hefty fee. Relative to the current situation and playing field: That is a harder one. I prefer not to answer it, hopefully you can answer it yourself after reading this faq. Q: What was the main motivation for writing this faq? A: The discussions with pro-standards advocatists were frequent and always follow the same pattern. They are also very tiring, specially if they react with animosity on *each* use of the term Pascal in one sentence with Borland or their products or compatibles somewhere near. I wanted to have a document to explain my points, without ending up in the usual bitter fights. Actually it was the ansi-iso faq from Scott Moore that inspired me to do this. (See links section) While I don't agree with all of his opinions, a high percentage of that FAQ is a neutral description of the situation, and even the opinionated parts (the advocacy) is a reasonable consistent description of his opinions and the reasons behind that, and therefore not a waste of time like some of the newsgroups discussions. Q: What are the Pascal Standards? A1: Official answer: (see above Ansi ISO faq) 0 Object Pascal ANSI technical report (1993) (never made standard) 1 Extended Pascal (ISO/IEC 10206 : 1991) 2 Unextended Pascal standard (ISO 7185 : 1990) with two levels (0: no schemata; 1: schemata) A2: de-facto answer (main famlies of Pascal dialects in current use:) The ones in A1 PLUS 3 Apple dialects (roughly ISO 7185 + Object Pascal + some extensions) 4 Borland Turbo Pascal, specially the last "7" release. 5 Delphi (hybrid between TP and own extensions modeled after, but not compatible with Object Pascal) _VAST_ For the rest there are several hybrids (Pascal-Java hybrids for early smartphones, Oxygene is a C# - Pascal hybrid, some Oberon derivatives named Pascal for marketing reasons, Objective Pascal (from FPC) that pulls in Objective C constructs needed for OS X/iOS interfaces). Even Borland/Inprise/Devco/Codegear/Embarcadero/Indera now joins the game with their Mobile offerings that borrow heavily from recent Apple concepts. In general, I ignore the hybrids, unless they can compile large subsets of existing Pascal code. (like FPC's Objective Pascal that only adds to existing modes/standards) (Historically important dialects and precursors like UCSD are omitted on purpose to not confuse the subject. The order is also roughly the order of use, least used first. I chose not to include Delphi.NET, Component Pascal and Java hybrids, because I consider these a bit (a lot?) further removed) Q: What's the problem with the Borland dialects from a standards point of view? A: Borland dialects are roughly a subset (P4) of ISO 7185 (P5) that got own extensions later. The subset thing seems to be the main gripe by standards obiding users. Scott Moore's FAQ has a reasonable list. The subset seems to be largely the same to the subset used for the bootstrap compiler P4. Q: What is the main problem with standards from an Borland oriented POV? A: Their low to zero usage, and their age (or: the stagnation of the process) increasingly makes them irrelevant to every days programming. - The playing field is dominated by Borland and compatibles to a very high degree. Borland's Turbo Pascal is one of the most succesful compilers of all time, mostly because it was one of the first cheap ones. - Besides Borland, the second largest Pascal group is the Apple using dialects (these are mostly standards compliant with a few system dependant extensions). However there never was a commercial OS X Pascal compiler, so Pascal on the Apple is a bit in decline. (some classic compilers can be tweaked though) On the other hand they probably form the second largest Pascal codebases after Borland, and this often is (sizable) production code. The numbers are dwindling though. - Besides these two big chunks (Apple admittedly being partially standards oriented), there are some standards based and other vendor specific dialects (often with UCSD heritage) in use in the mainframe and academic world. To my best knowledge this usage is low, and most of the compilers are in maintenance only state, or abandonned. Good, commonly carried Standards are productive, but the high profile days of Pascal are over, and the main benefits of standards are unification of various vendor dialects. Since unification efforts by letting dialects slowly gravitate towards eachother a la POSIX are too costly and thus unlikely, that makes standardization a bit pointless. So at least my main focus (and this probably goes for other FPC devels too) is on Delphi as the thing to be compatible with, albeit at arms length. A complete separate doc could be written about the relation with Delphi too, but sufficient to say, in the end we generally follow. Q: Are there Open Source standards compliant compilers? A: There is GNU Pascal. It is however very C-likein daily use. IOW the build system is not very Pascal like. Unfortunately the authors declared it dead. Besides that, FPC is slowly absorbing some standards features for easy migration of Mac users. Full compliance was not planned by core (fixing all cornercases is a lot of work), but patches will be accepted, and a specific mode will be added if there is sufficient interest (read: patches), and dedicated developers can get SVN access after they proved themselves. This already happened for non-extended Pascal, and I assume extended pascal could go the same way. If some standards people would actually decide to majorly invest in FPC iso compat, it would probably improve quite fast. That is a lesson learned from the speedy macpascal additions. It also proves that FPC is not unwilling to work with people that want to support other dialects. (since writing this Florian has been improving ISO 7185 mode as an hobby) Q: Define "EXTENSION"? A: An addition to a certain dialect. So I call adding an ISO construct that Delphi/TP doesn't have to FPC an ISO extension (relative to TP/Delphi). Q: What is the history behind FPC and the ansi-iso standards? A: For that we need a bit of FPC history: FPC originated on DOS as a compiler for the Turbo Pascal dialect, later went multi-OS mid nineties, slowly added Delphi support (d2 compat) in the late nineties and released 1.0 in the year 2000. The development of a 2.0 took five years, but with 2.0 the compiler now also supports the handful most used architectures and the basic Delphi compatibility is now near complete, with only a handful of features that require big changes left. Slowly the focus is shifting to the newer (2009+) generation of Delphis FPC is generally geared towards application development, not towards numeric (scientific) high performance computation, though it is decent enough to be able to use FPC for computational work. During 2003-2004, OS X and Classic Mac OS support were added, and for the first time, I saw significant interesting codebases that were non-borland in origin. (actually they were talked about in GPC context) After that FPC gained a developer interested in actively working on Mac Pascal support (and that indirectly included some standard Pascal constructs). FPC already had a policy that it would accept patches to improve ISO support for years (FPC added a GNU Pascal compability mode in the 1997-98 timeframe, roughly at the same time as the Delphi mode, to group ISO extensions, but no submissions were received). The interest from the Mac userbase was the first time somebody was interested in adding (some) standards compliancy, and willing to actively work on it. At first mainly the easy things were adapted, but now currently the more heavy problems are tackled. Unfortunately the process seems to have stalled again. This pretty much describes FPC (and its developers) pragmatic approach to the standards and extensions in general: "Who are you doing it for, and who will do the work?" Also the addition of ISO extensions till now has been prioritised by getting (assumingly validated) codebases to run, not with the target of becoming standards compliant as quickly as possible. This avoids lengthy discussions about corner cases. Q: What iso features does Free Pascal have? A: FPC 2.4.0 added readstr/writestr, 2.6.0 added an ISO mode. In 3.0+ basic ISO style file handing (filevariable^) and undoing borland reserved words were added. From the more major iso 7185 features, from what I can see, tagged union records and the associated new() handling is now the main missing feature. Maybe tempfile handling via the program xx() statement is one of the lesser features to be fixed. I can recall it took quite some effort on GPC's behalf to get that right Extended Pascal would be harder, with schemata and a revision of the module concept. Not that FPC makes it impossible, but more that it would require some serious, non piecemeal work. Q: What are the main missing language constructs in TP/Delphi/FPC with respect to ISO. A: For TP/Delphi, see the ansi-iso faq above. Note that there sometimes are ways to workaround problems relatively effortlessly. For FPC: the site to watch is http://www.freepascal.org/fpcmac.html A similar site for GPC: http://www.microbizz.nl/gpcdiffs.html (Apple specifics) Classically the main features missing in FPC from the above viewpoint: - support for passing nested procedures as procedure variables - support for interprocedural goto. both were added in 2.6.0. The first is often stated by Mac users as an absolute requirement, specially the ones that work strictly procedural. As a limited kind of closures more or less. Interprocedural goto's are often not that big of a fundamental problem, rewriting, though this easily can get laborous because purely procedural code might use it to jump out of deeply nested local procedures for error handling purposes. Note that in NG discussions ISO file handling is usually brought up as main ISO compat issue. However the above set of extensions comes from actual user requests, and generally they don't care that much about the filehandling. (probably because they have enough abstraction in place to keep production application' s fileformats independant of compiler stdio implementation, or never used stdio in non trivial apps to begin with. Keep in mind the Macers are already surviving their second architecture change, not counting 64-bit ones ) Other Apple (but non ISO) extensions: - Object Pascal objectmodel support. (everything virtual, creation via new/dispose, no constructors/destructors). Chances are that this can be mapped on top of Delphi classes, so that they are compatible. (maybe derivation compatible only _IF_ the base class is defined in Mac Pascal mode) - Objective Pascal (interfacing to Objective C/COCOA) Q: So in your opinion, Mac users should convert their codebases to non-ISO Delphi? A: No. Personally I would - set up new applications directly in Delphi dialect with FPC, maybe except when targeting classic Mac or other historic targets. - for existing codebases see if I can use FPC and use hybrid delphi-mac mode. While this ties one to FPC, it seems the most workable solution. Note that Mac mode isn't Mac specific, of course Apple Universal Interface use is. - for codebases with numeric calculation that can't be fast enough, ISO/Mac Pascal code in maintainance only mode and historic codebases that should be as little modified as possible: try to use GPC. In case of performance reasons: don't forget to benchmark GPC vs FPC for your specific application - If you don't like any of these options, IMHO the only option left is to actively start working on FPC's ISO support. Q: Another solution could be to merge extensions from practical use (delphi) into standards? A: This is not uncommon, see POSIX selecting best of breed from Sys V and BSD into new standards. However, Pascal is not "hot" enough for this anymore, and there are also no multiple vendors anymore that could pull off this effort and mutually benefit from the unification. Embarcadero/Borland's cooperation to implement missing standards features would be uncertain to say the least, since it is several magnitudes larger than any competitor. Open Source or commercial. (My) Conclusion: There is not much gain to expect _ANYMORE_ from standarisation efforts, except for ease of use for old ISO users. Most of these are in the Mac camp, and this group is searching for alternatives _NOW_. (well, this group also has been decreasing in the years since the original version of this document) Bad timing always seems to have been the problem of the Pascal standards. Maybe in the end the ISO 7185 mode in FPC will be decent enough for legacy maintenance. I doubt extended pascal will ever be implemented in FPC, it is too big and weird Links: FPC : www.freepascal.org FPC Mac/ISO page: http://www.freepascal.org/fpcmac.html GPC : www.gnu-pascal.de GPC Mac site: http://www.microbizz.nl/gpc.html GPC <-> Mac dialect differences and problems : http://www.microbizz.nl/gpcdiffs.html Scott Moore's Ansi/ISO site http://www.moorecad.com/standardpascal/ansiiso.faq