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

Chris F Clark <cfc@shell01.TheWorld.com>
Fri, 14 Jan 2011 17:04:05 -0500

          From comp.compilers

Related articles
[44 earlier articles]
Re: language design implications for variant records in a pascal-like compilers@is-not-my.name (2011-01-14)
Re: language design implications for variant records in a pascal-like mcr@wildcard.demon.co.uk (Martin Rodgers) (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 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)
[7 later articles]
| List of all articles for this month |
From: Chris F Clark <cfc@shell01.TheWorld.com>
Newsgroups: comp.compilers
Date: Fri, 14 Jan 2011 17:04:05 -0500
Organization: The World Public Access UNIX, Brookline, MA
References: 10-12-040 10-12-043 11-01-005 11-01-009 11-01-027
Keywords: parse, PL/I
Posted-Date: 15 Jan 2011 00:30:06 EST

PL/I style keywords (as opposed to Pascal style reserved words) are an
interesting topic to me, having used PL/I (as well as Pascal) and a
host of other older languages. The PL/I solution seemed elegant
enough that we used it in Yacc++ and documented how grammar designers
could apply it to their languages. The core idea behind the PL/I
solution is that there are many (or at least some) words that are only
reserved in certain contexts, and that if one isn't using the word in
that context there is no use in restricting the user from having it in
his vocabulary (i.e. available as a user defined identifier).


Froma a grammar writing point of view, it is not particularly
difficult to introduce PL/I style keywords to any LR grammar. The
same changes should generally work for LL grammars also. If people
are interested I can document them here.


The harder question one has to ask is whether they make writing
correct programs easier or harder. They certainly make more programs
legal and lessen the burden of remembering all the keywords for a
given 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.


This is the same reason implicit declarations can be dangerous.
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.


Hope this helps,
-Chris


******************************************************************************
Chris Clark email: christopher.f.clark@compiler-resources.com
Compiler Resources, Inc. Web Site: http://world.std.com/~compres
23 Bailey Rd voice: (508) 435-5016
Berlin, MA 01503 USA twitter: @intel_chris
------------------------------------------------------------------------------
[IF THEN = ELSE THEN IF = ELSE; ELSE IF = THEN; -John]



Post a followup to this message

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