Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.lang.misc
Subject: Re: PL/I and Reserved Words
Keywords: PL/I keywords
Message-ID: <4560@bd.sei.cmu.edu>
Date: 19 Oct 89 12:57:04 GMT
References: <2958@usceast.UUCP>
Reply-To: firth@sei.cmu.edu (Robert Firth)
Organization: Software Engineering Institute, Pittsburgh, PA
Lines: 32

In article <2958@usceast.UUCP> sharp@usceast.UUCP (Harry Sharp) writes:

>"Eventhough the capability to have variables like DECLARE and THEN, why would
> anyone ever use this?  Wouldn't it be hard even for the programmer to read?"

Good grief, I'm about to defend PL/I.

The problem the designers set out to solve is one very familiar to
maintainers of Cobol programs.  If the language words are reserved,
then any subsequent language enhancement that adds more reserved
words will invalidate a large number of existing programs that use
those words as identifiers.  I well remember a Cobol upgrade that
added over 40 (!) new reserved words.  That sort of thing leads to
coding standards that say

	Every identifier shall begin with "ZZ_"

in the hope that the result will be upgrade proof.

One alternative is not to reserve language words - not so that silly
people can use THEN and DECLARE as identifiers, but so that sensible
people who have used METHOD as an identifier won't be blown out of
the water by object-oriented PL/II.

Another, and I believe better, alternative is to use a separate font
or shift for language words, as was the practice with Algol-60 and
many of its descendents.  This alternative was unacceptable in North
America because programming languages had to be endorsed by manufacturers
of obsolete peripheral equipment.  Even Ada suffers from this disease.

Finally, one can always avoid enhancing languages.  (And yes, I too
prefer Fortran II to any of its descendents.)