Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!apollo!perry
From: perry@apollo.HP.COM (Jim Perry)
Newsgroups: comp.lang.misc
Subject: Re: PL/I and Reserved Words
Message-ID: <465396f5.20b6d@apollo.HP.COM>
Date: 19 Oct 89 20:29:00 GMT
References: <2958@usceast.UUCP> <4560@bd.sei.cmu.edu>
Sender: root@apollo.HP.COM
Reply-To: perry@apollo.HP.COM (Jim Perry)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 51
Keywords: PL/I keywords

In article <4560@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
>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.

Don't worry, you're in good company :-)

> [it protects you from changes to the language]

True, but it's also the case that compilers haven't had to rely on reserving
keywords for years, and there's no good reason for it.  PL/I defines a huge
number of keywords, in part because it provides synonyms for many of them.
I, who tended to be a good do-bee and spell out most keywords, e.g. "pointer",
might choose "ptr" as a simple list index, and would not be impacted (although
"ptr" is also a keyword).  Similarly, lots of programmers might elect to call
a pointer to the previous record "prec", although this is one spelling of 
"precision", an attribute of variables that is almost always defaulted.  

The fact that some bozo might elect to write something like 

    if if = then then then = else; else else = if;

opens the door to abuse, but this is true in many languages, and I'll just
point out that nobody's ever held an "obfuscated PL/I contest" or written 
a "PL/I puzzle book".  

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

Hm, maybe today you could get the right font effect, but in practice all
the efforts I've seen at this tended to overemphasize the keywords, e.g. 
by boldfacing them (crudely simulated by uppercasing) --

    IF dire_condition_prevails THEN die_horribly

the "if" and "then" in that statement are not the most interesting or
important parts.  This scheme also breaks down in modern languages with
redefinable types -- a declaration block or parameter list may contain
a long list of undifferentiated type names defined by your window manager
or whatnot, with an occasional boldfaced/italicized "integer" thrown in.
The fact that this word is meaningful to the compiler, and "window" isn't,
just doesn't interest me.  
Jim Perry   perry@apollo.com    HP/Apollo, Chelmsford MA
This particularly rapid unintelligible patter 
isn't generally heard and if it is it doesn't matter.