Hi!
First of all: Happy New Millennium! :-)
Peter and I are discussing the possibility of including some kind of conditional operator, like `foo ? bar : baz' in C. Since GPC uses GCC's backend, this should be easy to do semantically, the main question is about syntax:
- ?: like in C -- the symbols wouldn't conflict AFAICS, but it seems to me quite un-Pascalish...
- if foo then bar else baz (i.e., the same syntax as conditional statements, just with expressions, e.g. `x := if cond then 42 else 17'). Possible problems:
* dangling else (probably not since each conditional operator will be required to have an else clause)
* conflicts with `if' statements when nested into them (maybe not either for the same reason)
* issues with precedence (compared to other operators) and associativity (i.e., how nested conditional operators will be interpreted) -- C has the same issues and resolves them with some rules, but like all such issues, they can confuse programmers sometimes (think of precedence of `and' and `or')...
- if foo then bar else baz endif (or `fi' instead of `endif') -- this would avoid all the problems and make the syntax somewhat clearer I think...
- if foo then bar else baz end -- the same, but without introducing a new reserved word (of which there are already way too many), and `end' is unambiguous in this context AFAICS.
- Peter seems to remember that other Pascal compilers and related languages have something like this. Does someone know anything about these? Maybe we don't have to reinvent the wheel...
- Other suggestions?
Frank
Frank Heckenbach a écrit :
Hi!
First of all: Happy New Millennium! :-)
Peter and I are discussing the possibility of including some kind of conditional operator, like `foo ? bar : baz' in C. Since GPC uses GCC's backend, this should be easy to do semantically, the main question is about syntax:
?: like in C -- the symbols wouldn't conflict AFAICS, but it seems to me quite un-Pascalish...
if foo then bar else baz (i.e., the same syntax as conditional statements, just with expressions, e.g. `x := if cond then 42 else 17'). Possible problems:
dangling else (probably not since each conditional operator will be required to have an else clause)
conflicts with `if' statements when nested into them (maybe not either for the same reason)
issues with precedence (compared to other operators) and associativity (i.e., how nested conditional operators will be interpreted) -- C has the same issues and resolves them with some rules, but like all such issues, they can confuse programmers sometimes (think of precedence of `and' and `or')...
if foo then bar else baz endif (or `fi' instead of `endif') -- this would avoid all the problems and make the syntax somewhat clearer I think...
if foo then bar else baz end -- the same, but without introducing a new reserved word (of which there are already way too many), and `end' is unambiguous in this context AFAICS.
Peter seems to remember that other Pascal compilers and related languages have something like this. Does someone know anything about these? Maybe we don't have to reinvent the wheel...
Indeed, it was already in Algol60, the first ancestor of Pascal. The syntax was as above
x := if cond then 42 else 17
and I had some trouble in beginning with Pascal to give away this very natural syntax !
No dangling else, use of () to be sure in case of doubt about precedences would be the simplest (but I have an historical bias !)
Hope this helps
Maurice
Maurice Lombardi a ecrit :
Indeed, it was already in Algol60, the first ancestor of Pascal. The syntax was as above
x := if cond then 42 else 17
and I had some trouble in beginning with Pascal to give away this very natural syntax !
No dangling else, use of () to be sure in case of doubt about precedences would be the simplest (but I have an historical bias !)
Hope this helps
Maurice
As a native Algol60 speaker, I agree - this was one of the features I too missed when Algol60 faded away. Syntax is close to natural language (easy to teach, easy to learn, and a clean syntax - that is the fundamental principle of Pascal). The rules of precedence for Algol60 are basically evaluate from left to right unless specific rules apply - isn't that already the case for Pascal? I don't think we need anything else. The endif (or end) construction is un-Pascalish - use parentheses if required, in the same way as begin/end is used when needed for conditional statements.
Clive Rodgers
----------------------------------------------------------------------------- Atmospheric, Oceanic and Planetary Physics +44-1865-272905 (desk) Clarendon Laboratory +44-1865-272923 (fax) Parks Road Oxford OX1 3PU c.rodgers@physics.ox.ac.uk U.K. http://www.atm.ox.ac.uk/user/rodgers/
MIME, NeXTMail and SunMail attachments welcomed. HTML attachments tolerated Proprietary document formats (especially WORD) objected to. Use rtf instead -----------------------------------------------------------------------------
There's so many reactions :-), so let me do a mass-reply...
Clive Rodgers wrote:
Maurice Lombardi a ecrit :
Indeed, it was already in Algol60, the first ancestor of Pascal. The syntax was as above
x := if cond then 42 else 17
and I had some trouble in beginning with Pascal to give away this very natural syntax !
No dangling else, use of () to be sure in case of doubt about precedences would be the simplest (but I have an historical bias !)
Hope this helps
Maurice
As a native Algol60 speaker, I agree - this was one of the features I too missed when Algol60 faded away. Syntax is close to natural language (easy to teach, easy to learn, and a clean syntax - that is the fundamental principle of Pascal). The rules of precedence for Algol60 are basically evaluate from left to right unless specific rules apply - isn't that already the case for Pascal?
I think you can express it this way. I'd have said: Use operator precedence and if it's the same, use their associativity which is left for most operators and none for relational operators (i.e. `a = b = c' is invalid), but it seems to result in the same...
I don't think we need anything else. The endif (or end) construction is un-Pascalish - use parentheses if required, in the same way as begin/end is used when needed for conditional statements.
Probably. I think `if' without a terminator was basically a mistake (if only because of dangling else), and some later languages have corrected it, but it seems we have to live with it, also in this case...
However, why restrict it to the RHS? ISTR that in Algol68 (or was it SCL, the ICL VME operating system language) you could say:
if cond1 then a else b := if cond2 then expr1 else expr2
GCC has such an extension (over the C standard) for the ?: operator. I don't think the need for it is as big as on the RHS (though I'd probably find some places in my code where it could be used). But (at least when done straightforwardly), this syntax causes some parsing conflicts (with `if' statements, I assume), and might also be difficult to read because until reading the `else' it's not clear that this is no `if' statement.
or something like that, which could lead for example to (I think in SCL) the following curious-looking statement (until you worked out what it was doing):
if if then then else else := if not then while else for
Nice. :-)
since there were no reserved words (the compiler being sufficiently clever to work out when to expect one!). Fun to read anyway!
Well, GPC is doing something like this for words that are reserved only in some dialects (e.g., value). But these words above are reserved in all Pascal dialects, so GPC treats them as reserved unconditionally, and I think it should remain that way... ;-)
Tom Verhoeff wrote:
Peter and I are discussing the possibility of including some kind of conditional operator, like `foo ? bar : baz' in C. Since GPC uses GCC's backend, this should be easy to do semantically, the main question is about syntax:
I would like to propose the following syntax:
<expr> if <cond> else <expr>
This is concise and nice (you can view "if <cond> else" as infix operator). Disadvantage: it requires priorities/parentheses for proper binding, it uses the if/else, which also appears in the conditional statement (this is also an advantage, since it does not require new reserved words/symbols).
This doesn't seem to cause parsing conflicts, AFAICS. However, it's quite different from `if' statements (and therefore maybe confusing), so I'd tend to favour the if-then-else version...
However, this syntax seems to work on the LHS without conflicts, so the following seems possible:
a if cond else b := c if cond2 else d
So, I'd suggest either this syntax on both sides, or the syntax above only on the RHS...
Prof. Abimbola Olowofoyeku (The African Chie wrote: ^ (BTW, you have an `f)' missing there in your `From:' line.)
I have read the various comments about the Algol60 syntax - that is as good as any other. But like one of the other respondents, I am a bit concerned about compatibility with other Pascal compilers. This can of course be tempered by making sure that the new thing is rejected when other a switch for any other "standard" (e.g., BP, Delphi, EP, etc) is used, or perhaps, better still, to require a {$gnu-pascal} directive before it can be used. Does this make sense?
Yes (the former). It should be rejected/warned about when any dialect option is given. {$gnu-pascal}, however, just turns off all dialect options which is also the default, so requiring {$gnu-pascal} would be unsystematic/impossible...
Frank
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).
On 3 Jan 2001, at 5:05, Frank Heckenbach wrote:
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).
[...]
Well argued, Frank. Objections about compatibility with other Pascal compilers can be adequately dealt with by rejecting GPC extensions if another standard is switched on.
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.
True.
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...)
As someone who writes general purpose Pascal libraries I need my code to compile with as many compilers as possible. System-portability is not the only issue here.
Best regards, The Chief ------------ Prof. Abimbola A Olowofoyeku (The African Chief) Author of Chief's Installer Pro for Win32 Email: african_chief@bigfoot.com Web: http://www.bigfoot.com/~african_chief/
On 2 Jan 2001, at 5:34, Frank Heckenbach wrote:
- if foo then bar else baz (i.e., the same syntax as conditional statements, just with expressions, e.g. `x := if cond then 42 else 17').
As a former Algol 60 programmer, I too prefer this syntax. For a description of the syntax and semantics in Algol 60, see:
http://www.masswerk.at/algol60/report.htm
(Section 3.4 deals with "Boolean Expressions.")
-- Dave
On 2 Jan 2001, at 5:34, Frank Heckenbach wrote:
First of all: Happy New Millennium! :-)
Happy New Millenium from down under (we saw it first! but as usual, I slept through the Sydney fireworks ...).
Peter and I are discussing the possibility of including some kind of conditional operator, like `foo ? bar : baz' in C. Since GPC uses GCC's backend, this should be easy to do semantically, the main question is about syntax:
[...]
I have read the various comments about the Algol60 syntax - that is as good as any other. But like one of the other respondents, I am a bit concerned about compatibility with other Pascal compilers. This can of course be tempered by making sure that the new thing is rejected when other a switch for any other "standard" (e.g., BP, Delphi, EP, etc) is used, or perhaps, better still, to require a {$gnu-pascal} directive before it can be used. Does this make sense?
Best regards, The Chief ------------ Prof. Abimbola A Olowofoyeku (The African Chief) Author of Chief's Installer Pro for Win32 Email: african_chief@bigfoot.com Web: http://www.bigfoot.com/~african_chief/
-
Clive Rodgers -
Frank Heckenbach -
J. David Bryan -
Maurice Lombardi -
Prof. Abimbola Olowofoyeku (The African Chie