Re: language design implications for variant records in a pascal-like language

"robin" <robin51@dodo.com.au>
Mon, 10 Jan 2011 13:00:53 +1100

          From comp.compilers

Related articles
[26 earlier articles]
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2011-01-06)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2011-01-06)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2011-01-06)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2011-01-06)
Re: language design implications for variant records in a pascal-like bobduff@shell01.TheWorld.com (Robert A Duff) (2011-01-06)
Re: language design implications for variant records in a pascal-like DrDiettrich1@aol.com (Hans-Peter Diettrich) (2011-01-08)
Re: language design implications for variant records in a pascal-like robin51@dodo.com.au (robin) (2011-01-10)
Re: language design implications for variant records in a pascal-like gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-01-10)
Re: language design implications for variant records in a pascal-like haberg-news@telia.com (Hans Aberg) (2011-01-10)
Re: language design implications for variant records in a pascal-like compilers@is-not-my.name (2011-01-10)
Re: language design implications for variant records in a pascal-like martin@gkc.org.uk (Martin Ward) (2011-01-12)
Re: language design implications for variant records in a pascal-like martin@gkc.org.uk (Martin Ward) (2011-01-12)
Re: language design implications for variant records in a pascal-like DrDiettrich1@aol.com (Hans-Peter Diettrich) (2011-01-12)
[24 later articles]
| List of all articles for this month |
From: "robin" <robin51@dodo.com.au>
Newsgroups: comp.compilers
Date: Mon, 10 Jan 2011 13:00:53 +1100
Organization: Compilers Central
References: 10-12-040 10-12-043 11-01-005 11-01-009 11-01-027
Keywords: design, syntax
Posted-Date: 12 Jan 2011 00:14:10 EST

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>
>> Part of the design of PL/I was that you wouldn't have to learn all of
>> it to use it.
>
> A worthy goal.
>
>>...That was used as the reason for not having reserved
>> words. (You have to at least know the word to know not to use it.)
>
> I don't see that. I mean, you don't actually have to memorize the
> list of reserved words. You get an error message, saying you used a
> reserved word as an identifier, so you fix it and recompile.


That's assuming that the compiler actually tells you. The classic
case was a CDC COBOL compiler that didn't. It crashed, giving no
indication of what was wrong. It tured out that the first user word
was a reserved word.


However, for COBOL, the list was around 300 reserved words. Having to
waste a day's time (or a week's time in some sites) to get a message
back with error messages relating to a reserved word that had been
used inadvertently as an identifier was frustrating, to say the least.


> After a while, you've memorized all the reserved words you're
> likely to use incorrectly. Failure to know some obscure reserved
> word won't cause a (run-time) bug.


When there are hundreds of them, it gets tedious after a while.


That was part of the reason. The other reason was to accommodate
possible future additions to the language (or even alterations to the
language). If words are not reserved, then such changes can be made
without affecting existing programs. That has been justified time and
time again in both Fortran and PL/I which have been extended over the
past 40 or so years.


>> Also, the huge list of reserved words for COBOL may have been on the
>> mind of PL/I designers.
>
> Sounds likely. In other words, "COBOL has too many reserved words,
> therefore reserved words are evil, therefore let's eliminate reserved
> words." Overreaction?


Not at all. Just good compiler design. AFAIK, at that time FORTRAN
did not have reserved words. Neither did ALGOL. (Typical
implementations of ALGOL used underlining of keywords, or enclosed
keywords in apostrophes, so that keywords as such were not an issue.)



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.