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

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

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