Re: Ada.strings.bounded problems?

[stt@henning.camb.inmet.com (Tucker Taft)]

In article <1995Jan23.135503@lglsun.epfl.ch>,
Robb Nebbe <nebbe@lglsun.epfl.ch> wrote:
>... Clearly the semantics as they are defined, which allow the
>reemergence of predefined equality, are not desirable ...

Actually, the Ada 9X design team proposed in 1991 or thereabouts
that predefined operators would never "reemerge" in generics or 
composite operations.  However, at least at the time, there were
those who defended the Ada 83 behavior as *desirable*, mostly
based on examples where a generic which presumed predefined
semantics for an operator could become quite confused
if the operators did not satisfy various presumed invariants.
For example, one might presume that X < Y implied not X >= Y.
However, one could imagine an overriding of the predefined operators
such that there were "incomparable" values, and both X < Y and 
X >= Y would return False.  

At the time, the example that was mentioned several 
times was an overriding of user-defined operators 
to create modular arithmetic.  It was easy to
construct generics which could get pretty confused because
they presumed normal non-modular invariants such as
A > 0 implies A + B > B.  Text_IO.Integer_IO was one
possible example of this.

Although we (the design team) argued for no reemergence at 
the time, we ultimately reached the conclusion that, for 
untagged types, predefined operators should continue 
to reemerge, as they did in Ada 83.  I suppose
upward compatibility was the strongest argument, though the
argument about desirability and simplicity of semantics for
generics was considered as well.

Fully general support for user-defined "=" came somewhat later
during the Ada 9X design process, but in any case the goal
was to treat "=" *more* like other operators, rather than *less*.

Having decided to retain predefined operator reemergence for
scalar types, we were reluctant to make a special case for the
equality operator on untagged record types.  The same thing
applied to untagged derived types.  

Basically, we decided that tagged types would be used for
"fully" abstract types, since only on such types could you
handle levels of indirection, etc., where a user-defined
equality was clearly important.  

In other words, we decided to keep uniformity across all
untagged types, and across all tagged types, but sacrifice 
some uniformity between tagged and untagged types.

The general "philosophical" difference between tagged types
and untagged types is that untagged types are simpler and
leaner and better for relatively "concrete" types, whereas
tagged types are a bit more expensive but more flexible and
better for more "abstract" types.  

For derived types, untagged derived types are presumed 
to be types that are essentially identical internally, 
but with a strong type distinction created between them to help 
support compile-time checking of one sort or another (such
as two integer types where one counts apples and the other oranges).  

Tagged derived types (i.e.  type extensions), on the other hand, 
are potentially completely different internally from their parent
type, and it is intentionally possible to *avoid* strong 
compile-time type distinctions between them by using a class-wide type,
which makes sense when the differences are merely implementation
differences, rather than significant interface differences.

Or in short, untagged derived types can be used to create arbitrary
interface differences on top of identical implementations, whereas
tagged type extensions can be used to preserve a common interface
across significantly different implementations.

>Maybe the cost of not providing consistant semantics between tagged
>and untagged record types will exceed the cost of introducing an
>upward incompatability, maybe not.   ...

There was also the issue of consistency between untagged record
types and untagged non-record types.  As mentioned above, we chose
to make the "break" between tagged and untagged.  One could instead
have made the break between records and non-records, but we felt
that was not as natural a breaking point, particularly since in Ada 83,
one could implement a given private type with a record or a non-record
without any signicant effect on the clients.

> ... It is a really tough call right
>now. Especially since there really isn't any data, just speculation,
>to base the decision on.

It is always painful to break consistency.  Clearly the issue
of reemergence of predefined operators will continue to reemerge
over time ;-).

>Robb Nebbe

-Tucker Taft  stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.