Ada '88 Proposals

Ada '88 Proposals

[stt]

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.

Re: Ada '88 Proposals

[stt]

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

Re: Ada '88 Proposals

[Brosgol]

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)