Version 1.1 of ais/ai-00304.txt

Unformatted version of ais/ai-00304.txt version 1.1
Other versions for file ais/ai-00304.txt

!standard 12.5(8)          02-07-11 AI95-00304/00
!class amendment 02-07-11
!status received 02-07-11
!priority Low
!difficulty Hard
!subject Reemergence of "=" in generics.
!summary
!problem
!proposal
!wording
!example
!discussion
!ACATS Test
!appendix

From: Tucker Taft
Sent: Thursday, June 13, 2002  8:31 PM

Robert A Duff wrote:

> Randy said:
>
> > Deleting bounded strings would make more sense. :-)
>

...

> But the implementation of Bounded_Strings initialized all 1000
> characters (because some AI says "=" has to compose on these things)!

It might be time to address this issue directly, namely that "=" reemerges in
generics, and doesn't compose.  We have special rules for the "=" operator for
tagged types, why not make this operator special for all types, requiring that
if user-defined using the base subtype for scalar formals, or the first subtype
for other types, then the predefined one does *not* reemerge in generics, and
it composes properly.

Yes, I realize this would not be upward compatible, and would not be
the same as other operators (but those don't *need* to compose), but
remember that until Ada 95, it was very difficult to define your own equality
operator anyway on a non-limited type.

At the very least, we should do this for record and private types.  And of
course, once you do it for private types, things get weird if you don't
do it for all types.

****************************************************************

From: Tucker Taft
Sent: Thursday, June 13, 2002  9:25 PM

Anticipating the "shared generics" implementation problems,
I humbly recast this as a proposal to make user-defined "="
compose properly and hide the predefined "=" in generics
only for record types (and for private types that are record
types "deep down").

****************************************************************

From: Tucker Taft
Sent: Thursday, June 13, 2002 10:27 PM

> Anticipating the "shared generics" implementation problems,

Nice to hear that some people are responding to the training. :-)

> I humbly recast this as a proposal to make user-defined "="
> compose properly and hide the predefined "=" in generics
> only for record types (and for private types that are record
> types "deep down").

From a shared generics perspective, it would make more sense to simply have
this happen for generic formal private types (and maybe generic formal
derived record types?). After all, we'd need to use a thunk for any generic
formal private "=", so why shouldn't all types work right in that context.
Redefinition of "=" on elementary types is a lot rarer, and both the
compatibility issues and the runtime cost wouldn't be worth it.

But my gut feeling is that this is too incompatible to consider. People have
been working around this problem since time immemorial (i.e. 1983), and we'd
have to make sure that all of the workarounds still worked.

****************************************************************

From: Pascal Leroy
Sent: Saturday, June 15, 2002  4:46 AM

> Yes, I realize this would not be upward compatible, and would not be
> the same as other operators (but those don't *need* to compose), but
> remember that until Ada 95, it was very difficult to define your own
> equality operator anyway on a non-limited type.

Well, Ada 95 has been around for 7 years, and the Ada 83 trick was well
publicized at the time, so I think that we cannot afford the
incompatibility.

On the other hand, if we had a mechanism to specify, on the declaration of
"=", that it has to compose and doesn't reemerge, that would be both
compatible and useful.  It could be done by some sort of
pragma/attribute/new syntax/whatever.

****************************************************************

From: Bob Duff
Sent: Saturday, June 15, 2002  7:24 AM

As a pragma, it violates Bob Duff's Rule of Good Taste in Pragmas,
which is, "Pragmas should not have a strong effect on high-level
semantics."

As new syntax, it's ugly, because you always want it.

But I admit that one of these is probably the best solution,
given the (rather subtle) upward compatibility concern.

****************************************************************

From: Pascal Obry
Sent: Saturday, June 15, 2002  7:24 AM

Right, but would be quite cleaner than introducing a pragma. In such
a case the compiler could certainly warn and point out where the
compatibility problems are, no ?

****************************************************************

From: Bob Duff
Sent: Sunday, June 16, 2002 12:17 PM

> Right, but would be quite cleaner than introducing a pragma.

Sorry, I don't understand what you mean.

>... In such
> a case the compiler could certainly warn and point out where the
> compatibility problems are, no ?

Yes, a compiler could warn if you pass a type with user-defined "=" to a
generic, and call "=" in the generic.  Also if you declare a record or
array component with user-defined "=", and call "=" on the outer thing.

In fact, such a warning might be useful even if the language is *not*
changed.

****************************************************************

From: Tucker Taft
Sent: Sunday, June 16, 2002 12:17 PM

> Sorry, I don't understand what you mean.

I meant that I think it would be better to "fix" the language by introducing
an slight incompatibility (the compiler will issue a nice warning to help
the migration) than to have a new pragma that change the semantic.

> In fact, such a warning might be useful even if the language is *not*
> changed.

Agreed.

****************************************************************

From: Robert Dewar
Sent: Sunday, June 22, 2002 11:12 AM

I am *completely* opposed to ANY deliberate incompatible changes at this stage.
None of the "improvements" to Ada being discussed is remotely worth the effort
of dealing with having to make changes in large legacy programs as a result
of gratuitous incompatibilities.

If we could not successfully argue for this incompatible change for Ada 9X, it
is sheer folly to consider sneaking it in for the next version of Ada.

Speaking for ACT, if any updated version of Ada has incompatibities of this
nature it would be sufficient for us to simply ignore the new feature. We
cannot afford to affect existing customers in this manner.

The idea that when you recompile millions of lines of legacy code that a
warning will be sufficient help to safely change code with minimal effort
is bogus!

****************************************************************




Questions? Ask the ACAA Technical Agent