stt@inmet.UUCP (07/11/87)
Here are various proposals for Ada '88 being submitted
to the Ada Language Issues Working Group.
I am presuming that no proposed change should make existing
legal programs illegal, though clearly they should make
existing illegal programs legal (or else what's the point?).
Furthermore, most of the things I am proposing represent
relaxing arbitrary language restrictions which can already be
circumvented, but only by circuitous nonintuitive methods,
and hence don't significantly "relax" the strictures
of the language.
Tucker Taft
c/o Intermetrics, Inc.
Cambridge, MA 02138
stt@INMET.INMET.COM; ...{ihnp4,harvard}!inmet!stt
1) The full definition of a private or incomplete type
with discriminants should be allowed to be a derived type,
providing that the parent type has discriminants with conforming
names, types, and defaults. An approximate equivalence can
be accomplished now by having the full definition be
a record enclosing the desired parent type as the single
non-discriminant component, though this almost certainly
introduces significant additional overhead and complexity.
2) Initialized constants of limited type should be legal.
Since limited type subprogram IN parameters may have defaults,
this is equivalent to declaring a subprogram with a single
parameter with the initial value as the specified default,
and then calling it providing no explicit parameter.
To be consistent, a generic object IN parameter of limited
type should also be legal.
3) Conversion should be considered static when the value
is discrete and static, and the target subtype is discrete and static.
This can be accomplished currently by using the circuitous
route of a qualified expression above a "'POS" attribute call.
4) There should be some way to explicitly allow or disallow
actual generic types being unconstrained in the generic spec.
A proposed syntax would be:
type A(<>) is private; -- Unconstrained allowed
type A() is private; -- Unconstrained disallowed
5) The "=" operator should be definable on any type, so
long as the result type is Standard.Boolean (so "/=" is
well defined). It is currently possible to accomplish the
same thing by a clever use of generics and renaming.
The original rationale for disallowing the hiding
of pre-defined "=" by a user-defined operator is probably
that when used as a component the predefined "=" is used
for the enclosing object. However, there is good precedent
that predefined operators reemerge in certain circumstances,
such as the definition of membership, without precluding
their explicit hiding.
6) The LRM should specify the default rep for enumeration
types in the absence of a representation clause. Otherwise,
every enum type which is to have the "conventional"
rep (where the value = the 'POS) will need a rep clause if it is ever
to be written out in binary form to the external environment.
Similarly, the default rep for integer types
should be specified as being unbiased (where the value = the 'POS).
Furthermore, the LRM should specify the layout of arrays
indexed by enumeration types with representation clauses. I.e.,
if the enumeration rep has gaps,
should the array have gaps or should its elements be contiguous?
7) Change the semantics of exception declaration to improve
the feasiblity of sharing code between generic instantiations.
Currently a new exception is created for each instantiation at compile-time,
but not for each elaboration at run-time. This is the worst
possible approach when trying to share code.
The current situation means that even though all of the
code may be shared between two instantiations, exceptions
declared anywhere within the generic body must somehow
be exported out to unshared code (within the instantiator
presumably) and then have their "address" passed back into
the instantiation as an implicit generic parameter.
Either exceptions should be created only by explicit declarations
in their original code (whether generic or non-generic), or
should be created at each elaboration. I personally favor
the latter since it is consistent with all other entities, including
types, program units, and objects. What this would mean is that
an exception declared within a subprogram would be unique to
the particular subprogram execution. Since the declaration is only
visible to itself, and its nested units, the only
time it would matter is when the exception is propagated to
a recursive call made from itself or some nested unit,
which is of limited value anyway. It is always possible
to move the exception definition out a level if there is
any real need for handling local exceptions in recursive calls.
I would venture to say this would not affect any existing
code.
Without this change, the correct implementation of generic sharing
will be significantly more complicated, and less likely to
be supported in most Ada compilers any time soon.jbg@SEI.CMU.EDU (07/15/87)
Lest readers of Tucker Taft's message be misled, note that there is no official activity underway that would lead to a revised Ada standard being issued in 1988, either as a military, ANSI, or ISO standard. 1988 surfaces as a date because all ANSI Standards are reviewed every 5 years to see if they should be retired or revised. Clearly, in response to this inquiry in 1988, the AJPO will say the Standard is still needed. It would also be reasonable to say at that time that revisions are anticipated at a later date, but probably any such revisions would not be approved in a revised Standard until some time in the 90s. Hence, it's better to refer to the revised Standard as Ada 9X instead of Ada '88. Note that the revision cycle for other languages is about once every ten years; I don't expect Ada will be any different. Of course, this doesn't mean it's inappropriate to discuss possible changes now; quite the contrary.
stt@inmet.UUCP (07/17/87)
I have received several inquiries since posting this note about Ada '88 language change proposals, asking, roughly, "What is the Ada Language Issues Working Group?" I learned of their existence from reading the July/August Ada Letters, where they have their minutes from their 12 January 1987 meeting. Their next meeting will be at the August SigAda meeting in Seattle. Quoting from the minutes: "To place a recommended Ada feature on the agenda, contact one of us at the addresses below. ALIWG Chair: ALIWG Secrectary: David A. Smith William Currie Colket Hughes Aircraft Company MS360 Code 1013 8000 E. Maplewood Ave. Naval Air Development Center Englewood, CO 80111 Warminster, PA 18974 (303) 793-5226 (215) 441-2149 DASMITH@ADA20.ISI.EDU COLKET@NADC In the minutes, they indicate that the ALIWG charter is to "provide a forum for discussion and review of the Ada language definition . . . Changes supported by the group will be submitted to the AJPO . . ." Tucker Taft c/o Intermetrics, Inc. Cambridge, MA 02138
Brosgol@MIT-MULTICS.ARPA (07/20/87)
In case there was any confusion about who is ALIWG, it is a working group under the Users Committee of ACM SIGAda. Any recommendations coming out of ALIWG reflect only the opinions of the participants and do not necessarily reflect the opinions of SIGAda, ACM, or any other organization. I sometimes get weary reading disclaimers such as what I provided above, but in the July-August Ada Letters there was an insufficient identification of exactly who ALIWG is (at least in their submitted paper) and thus I think that some clarification was in order. -Ben Brosgol / ACM SIGAda Chair (as of 1 July 1987)