Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion language design implications for variant records in a pascal-like language
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
compil...@is-not-my.name  
View profile  
 More options Jan 16 2011, 6:02 am
Newsgroups: comp.compilers
From: compil...@is-not-my.name
Date: Sun, 16 Jan 2011 11:02:27 -0000
Local: Sun, Jan 16 2011 6:02 am
Subject: 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]

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.