Re: Ada language revision

[stt@inmet]

"Official" revision requests for Ada will ultimately have
to be sent to "ada9x@ajpo.sei.cmu.edu" following
a detailed format similar to language comments
as specified in the back of the Ada LRM, but with
many more standard paragraphs, including
"!keywords", "!summary", "!specific requirement/solution criteria", etc.
The primary emphasis is to state *requirements* which are currently
felt to be unanswered by Ada, rather than specific solutions.
The official revision request format will probably be announced soon.

It's pretty easy to indulge in Ada bashing, or Fortran bashing,
or Pascal bashing, etc.  However, the ada9x effort will probably
be most responsive to carefully argued points.  The following
2 points by <billwolf@hubcap.UUCP> would be easier to understand
if they identified the LRM paragraph of the mentioned "rule".
As far as I know, no such rules exist.

>>  3) The rule that a limited private type cannot be a direct component of 
>>     another limited private type should be repealed.  

Perhaps the issue is that non-limited types may not have components
of limited types?  (I agree this is annoying, though defensible.)

>>  7) Arrays should be initializable via named association.  It is very 
>>     tedious to write out 37 Falses simply in order to initialize the
>>     38th element of a Boolean array to True before I can finally specify 
>>     that all other elements of the array are False. 

Named aggregates are legal to initialize arrays.  Perhaps the issue
is the use of "named" notation in conjunction with "others =>".
This is never permitted in places where implicit array subtype
conversion (aka "sliding") is legal because there is no way of knowing what
is the first element of the aggregate (it may be one of the named
elements, or it may be one of the "others").
To avoid this problem, a qualified expression may be used,
specifying the subtype of the array aggregate explicitly,
which implies the low and high bounds.

Generally I agree with the spirit, if not the details, of these
requests.  But to be effective, they must be as formally
and carefully stated as possible.

Tucker Taft   stt@inmet.inmet.com; ...!uunet!inmet!stt
Intermetrics, Inc.
Cambridge, MA  02138