I'm separating out this point from the reply concerning syntax...
Clive Rodgers wrote:
As another ex-Algol60 (my first language on an Elliot 503, just to show my age!) this is quite natural but I am not sure that there is that much to recommend it since it would make the program much less portable to other Pascal environments. I think the gpc team should be careful not to go too far down a divergent route. After all, open standards are there for guidance and to avoid some of the more destructive activities of certain Large Companies and it would be a little hypocritical of open source advocates to follow this bad example.
Yes, but let me claim that (partly due to the influence of a certain Large Company), this has already happened. Basically, in the "Pascal world", there are (at least) two different "continents", the standard one (Standard Pascal, Extended Pascal) and the Borland one (Turbo Pascal, Delphi), and there doesn't seem to be any sign of them converging again -- i.e., neither from Borland nor any maker of other compilers focussed on BP compatibility I've seen any intent of becoming standard conforming (or anywhere close to it), and OTOH many BP features are no likely candidates for inclusion into a future Pascal standard (if there will ever be any).
Furthermore, I claim that both language families lack some important features that are sometimes needed in real-world programs, so when using one family, one has to work around its limitations. I'll give some examples (with typical work-arounds) -- that's only about language syntax and features, not about library routines (which are easier to add in the form of units/modules):
BP:
- schemata (over- or undersized type declarations and SizeOf and GetMem/FreeMem)
- passing local routines as procedural parameters (only with assembler code)
- ReadStr/WriteStr (series of Val/Str, Copy/+ and other operations)
- initialized variables (typed "constants")
- generalized Succ/Pred (Ord/Chr for Char; [Ord and] type casts for enum types)
- variables of dynamic size (again, GetMem etc.)
- ...
SP:
- integer types of different sizes (self-made long number arithmetic for larger types; using Char and manual conversions to read/write smaller types from/to files)
- type casts (abuse of variant records -- which in itself is neither compiler-portable nor system-portable)
- compiler directives (no work-around)
- address operator (allocate things dynamically if you ever need their address)
- linking to external code, e.g. C libraries (no work-around, only compiler-specific ways)
- ...
Both:
- choice of integer types with a given sizes (BP: rely on the sizes introduced on 16 bit platforms as though they're carved in stone; SP: self-made arithmetic, see above)
- support for endianness (SP: hope to get some conditional compilation and hard-code a list of LE/BE targets; BP: the same or just assume little-endian)
- ...
As a consequence, since I'm quite tired of using such work-arounds in my code, I really "have" to use a combination of both, and AFAIK, GPC is the only compiler to offer that. So, almost all of my code requires GPC for that reason and I don't make it any less compiler-portable by using any (existing or new) GPC extensions. I might think different about it if there was any evidence for other compilers supporting this combination, but from all I've seen it's quite a safe bet this will never happen. (Another thing is that I don't consider compiler-portability nearly as important as system-portability, since what do I gain if I can compile my sources with 5 different compilers, but all on the same 3 or 4 systems...)
(Yes, this was talking about my own Pascal code, but nobody is forced to use any particular feature, so those who think different about their code, just don't use it...)
To see the whole thing somewhat more positively, let me also claim that (on a large scale) the development of programming languages is far from completed. Computer science and programming still is a rather new thing, and still new experiences with languages are made and consequences drawn. This does not only refer to big new concepts like OOP, but also to details and small improvements to the basics (like the conditional operators this is about).
As someone interested in programming languages, I consider this a good thing, but as a programmer, it leaves me the choices to:
- Stick to some language and watch it (and with it my code) get obsolete...
- Jump to the language-of-the-day every other year and abandon or rewrite my old code...
- Find a language that can be extended and changed (like I do :-)...
In this regard, it might even be seen as a plus that there are no strong standards in Pascal, so there's more room to "play" (again, for those who want it, nobody will be forced to use any new feature, and the existing standard or BP compatible features won't disappear).
One criterion for a good new feature is to me that it either makes things possible that were not possible (or only with dirty tricks) without it, or that it allows to write code shorter than without it, since shorter code is usually easier to understand and leaves less room for bugs. (`short' as in using fewer tokens (roughly), not using shorter identifier names or obscure symbols instead of keywords, of course.) I've spotted many places in my code where a conditional operator would achieve the latter (by saving me from writing two similar assignments in the then/else branches of an `if' statement, and/or using a local variable), so I consider it a useful extension...
Frank
PS: What open source advocates get most upset about the behaviour of certain Large Companies WRT to open standards vs. proprietary extensions is, I think, that they (a) don't document their extensions and therefore make it hard/impossible for others to be compatible (the typical example here is the Microsoft Word format) and/or (b) to not implement the existing standards in the first place or implement them so inefficiently that users of their systems won't use them (this applies to Microsoft WRT to POSIX, Java, many Internet protocols, and probably much more just as well as to Borland's Pascal dialect). That's not what we do with GPC (if the documentation is currently missing some features, that's for lack of time and contributors, but we'll be happy to explain any feature we've introduced when asked).