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

compilers@is-not-my.name
Sun, 16 Jan 2011 11:02:27 -0000

          From comp.compilers

Related articles
[46 earlier articles]
Re: language design implications for variant records in a pascal-like robin51@dodo.com.au (robin) (2011-01-14)
Re: language design implications for variant records in a pascal-like robin51@dodo.com.au (robin) (2011-01-14)
Re: language design implications for variant records in a pascal-like robin51@dodo.com.au (robin) (2011-01-14)
Re: language design implications for variant records in a pascal-like DrDiettrich1@aol.com (Hans-Peter Diettrich) (2011-01-14)
Re: language design implications for variant records in a pascal-like cfc@shell01.TheWorld.com (Chris F Clark) (2011-01-14)
Re: language design implications for variant records in a pascal-like robin51@dodo.com.au (robin) (2011-01-15)
Re: language design implications for variant records in a pascal-like compilers@is-not-my.name (2011-01-16)
Re: language design implications for variant records in a pascal-like gah@ugcs.caltech.edu (glen herrmannsfeldt) (2011-01-16)
Re: language design implications for variant records in a pascal-like robin51@dodo.com.au (robin) (2011-01-17)
Re: language design implications for variant records in a pascal-like torbenm@diku.dk (2011-01-17)
Re: language design implications for variant records in a pascal-like dot@dotat.at (Tony Finch) (2011-01-17)
Re: language design implications for variant records in a pascal-like genew@ocis.net (Gene Wirchenko) (2011-01-17)
Re: PL/I arcana, was language design implications for variant records compilers@is-not-my.name (2011-01-17)
[5 later articles]
| List of all articles for this month |

From: compilers@is-not-my.name
Newsgroups: comp.compilers
Date: Sun, 16 Jan 2011 11:02:27 -0000
Organization: Compilers Central
References: 11-01-057
Keywords: PL/I, history, comment
Posted-Date: 16 Jan 2011 14:26:37 EST

> However, if one has written an incorrect program, they might make
> deciphering the error message harder and may prevent the error being
> detected at the spot where it occurs. For example, consider the case
> where someone doesn't realize that a specific keyword has a language
> defined meaning at a particular spot and in the same spot an ordinary
> user defined identifier is allowed. Then, in that place if the user
> types what they think is their user defined identifier, but it happens
> to be a reserved word in that context, something bad will happen. If
> the user is lucky, the mistake will cause some kind of error because
> the keyword will have additional syntax following it that the user
> will not specify. In the unlucky case, the program will appear
> correct, but silently do the wrong thing, possibly not detected until
> it has caused some later catastrophic failure.


I don't know if the source for it was ever made public, but PL/C, a
variant of PL/I written at Cornell University would be a great case
study on this topic.


I'm sure many guys on the list are old enough to remember, but for
those who aren't or who didn't work on IBM platforms, the idea behind
PL/C was to hammer anything you handed it into a legal PL/I program
and generate a working load module (executable). The program may not
have done what you wanted, but it would do *something*. It was
targeted at CS101 students and from what I saw sitting behind the Help
Desk it did a credible job. I wish I could remember more about it.


The diagnostics ranged from helpful to hilarious. When it detected a syntax
error it would correct the statement as well as it could and produce a
message "PL/C USES... " and give a working syntax for the statement, which
was inserted in the program at that point.


I don't know how much the thinking or logic behind it would lend
itself to other languages. But it was a very interesting teaching
concept.


> This is the same reason implicit declarations can be dangerous.


I'm not sure I agree with this or else FORTRAN couldn't have been very
successful. A lot of non-optimal things in life do seem to work.


> Certain types of errors are easy to make and systems that make that
> harder provide more protection, even if they penalize those who don't
> make those errors.


Ada!


> [IF THEN = ELSE THEN IF = ELSE; ELSE IF = THEN; -John]


Ha! When I get a chance I may try compiling that under PL/I...!
[For more info about PL/C. see http://ecommons.cornell.edu/handle/1813/5952
I don't know if the code is still around, but it'd be easy enough to
ask if anyone wants to run it on Hercules.
With respect to the danger of implicit declarations in Fortran, there are
plenty of stories of broken code due to statements like DO 10 I = 1.10
which is an assignment, not a loop. -John]


Post a followup to this message

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