From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 16 Apr 93 09:24:00 GMT
From: pipex!uknet!warwick!zaphod.crihan.fr!univ-lyon1.fr!scsing.switch.ch!sicsu
n!disuns2.epfl.ch!lglsun!magnus@uunet.uu.net  (Magnus Kempe)
Subject: Re: Ichbiah's Letter
Message-ID: <1993Apr16.112002@lglsun.epfl.ch>
List-Id: <comp.lang.ada>

In article <C5J0I4.Dn1@crdnns.crd.ge.com>, groleau@e7sa.crd.ge.com (Wes Groleau
 X7574) writes:
: The trailing underscore is a quick fix that can be easily automated.  It is
: NOT a good idea to allow it to remain in code when actually doing maintenance
: on that code.

Right.  Don't you think maintainers will find code in 2015 with
trailing underlines all over the place?

If the goal is really to allow quick, automatized fixes, wouldn't it
be much easier to change the old identifiers into something that uses
the upper-half of ISO Latin-1 (the 8-bit character set that will
replace ASCII in Ada 9X)?  For example, one could choose to change
systematically "Tagged" (old identifier) into "Tagged_83X" (new
identifier since "tagged" is now, needlessly, reserved) where X is,
say, some _striking_ glyph like the section sign (paragraph sign,
"inverted-P-with-bar", decimal code 167).

The characters found in the upper-half of Latin-1 do not exist in ASCII
(since it is/was 7-bit), so such a scheme is as safe as possible.

This approach wouldn't be a "quick fix," and wouldn't defile the beauty of
Ada.  On the other hand, allowing trailing underlines is an invitation
to abuse.  Further, consider what the Ada 83 Rationale states on the
topic of allowing single underlines _in_ identifiers:

  "... an underline character may appear between two other characters
   of an identifier.  This underline is significant and plays the role
   of _space_ in ordinary prose ... the significance of the underline
   makes SPACE_PER_SON a different identifier from SPACEPERSON or
   SPACE_PERSON ..." (p. 6, emphasis mine)

Now, add three unreadable variants: SPACE_PER_SON_, SPACEPERSON_,
SPACE_PERSON_.  How many Ada programmers (code maintainers) explicitly
look for/count with trailing underlines when reading Ada code?  Now, you
can't just assume that identifiers are sequences of words separated by
underline, since identifiers are sequences of anything from beginning to
end, including underlines (except you still can't have two underlines
in a row).  It is quite likely that a lot of coding guidelines will
simply state that "Thou shall not use trailing underlines."

So what's the use?  Is the "quick fix," changing the language, justifiable?


Keywords vs. more reserved words

: There is a tr[e]mendous risk of complexity in semantic analysis
: if words like "until" or "tagged" are not reserved.

The only problem is merely one of syntax analysis:

  type T is tagged private; -- if "tagged" is_ followed by "limited",
                            -- "private", "null" or "record", it's a keyword

  type T is Tagged .. 10;   -- if it is_n't, it isn't (note the use of an
                            -- underline to remove the ambiguity, like it? :-)

Looking at the grammar, I don't think there is room for ambiguity with
"tagged".  Same thing applies for "until", "protected", "aliased" and
"requeue."

So where is the "semantic complexity"?  Should we plan for future revisions
of the language?  (E.g. resolve against the addition of any more reserved
words, just define keywords if needs be?)
-- 
Magnus Kempe                "No nation was ever drunk when wine was cheap."
magnus@lglsun.epfl.ch                                   -- Thomas Jefferson