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

Robert A Duff <bobduff@shell01.TheWorld.com>
Thu, 06 Jan 2011 17:24:01 -0500

          From comp.compilers

Related articles
[24 earlier articles]
Re: language design implications for variant records in a pascal-like torbenm@diku.dk (2011-01-04)
Re: language design implications for variant records in a pascal-like jm@bourguet.org (Jean-Marc Bourguet) (2011-01-05)
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)
[28 later articles]
| List of all articles for this month |

From: Robert A Duff <bobduff@shell01.TheWorld.com>
Newsgroups: comp.compilers
Date: Thu, 06 Jan 2011 17:24:01 -0500
Organization: The World Public Access UNIX, Brookline, MA
References: 10-12-040 10-12-043 11-01-005 11-01-009
Keywords: design, storage

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. 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.


At least, that's true if the compiler gives good error messages about
obscure reserved words. "Reserved word 'until' used as an
identifier.", as opposed to "Compiler saw 'until', and is now
hopelessly confused...<cascade of junk messages>". That requires the
language syntax to make such good error messages feasible -- which is
more-or-less the same sort of syntax that can allow a
reserved-word-free syntax.


> 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?


- Bob
[Back when PL/I was designed, "recompile" meant resubmitting a deck of
cards and potentially waiting several hours. To avoid that problem,
COBOL programmers did wacky things like starting all variable names
with a digit, just to avoid the reserved words. These days I agree,
reserved words are less of a big deal, but modern languages don't have
400 reserved works like COBOL does. -John]



Post a followup to this message

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