Overridability of _private_ predefined "=" [was Re: list strawman]

Overridability of _private_ predefined "=" [was Re: list strawman]

[Vincent Marciante]

Mark Lundquist wrote:
> 
> "Thomas Wolf" <t_wolf@angelfire.com> wrote in message
> news:MPG.16a629ebab6a7b63989682@news.ip-plus.net...
> > Some comments on that Strawman 1.4 interface:
> >
> > 1. Generic formals
> > ------------------
> >
> >    generic
> >       type Element is private;
> >    package Containers.Lists.Unbounded is
> >
> > I'd prefer
> >
> >    generic
> >       type Element is private;
> >       with function "=" (Left, Right : Element) return Boolean is <>;
> >    package Containers.Lists.Unbounded is
> >
> > This allows users who have unconventional ideas of equality to provide
> > their own routine, without requiring "normal" users to specify the
> > equality function explicitly.
> 
> Indeed it's a bug in Ada95 if the generic uses "=" without importing it
> explicitly.  Otherwise, an overridden "=" is not visible to the generic, and
> predefined equality "reemerges".

Its even worse than just that.  Now a "block compare" of any composite
type
that has a nontagged private type as a componant is questional because
that
comparison will utilize the predefined "=" of the private type even
though
the creator of the private type may have seen it proper to overridden
it.

There was a thread, gosh, I guess less than two years ago where I was
trying to
argue that this was a disaster wrt generics and that reemergence of "="
seemed
to be a special case wrt the whole reemergence issue.   I now feel that
the
situation is very bad in general as opposed to being bad only wrt
generics.

Does anyone think that it would be good for there to be a change in the
language such that for private types, if a primative "=" returning
boolean exists then it
should be the "=" used as part of block compares and that the predefined
one
should not reemerge in generics?  This would not have been incompatible
with
Ada83, right?

I hope that the above is not perceved as rehashing old arguments - I do
not
remember the issues having been discussed exactly as above.

Vincent Marciante

Re: Overridability of _private_ predefined "=" [was Re: list strawman]

[Christoph Grein]

Please, before going into further discussions about reemergence of predefined 
operations and thinking about changing the language, read the corresponding 
chapters in the AARM (the Annotated Ada Reference Manual), e.g. AARM 
4.5.2(24a-c).

With respect to "block compare", this is not possible for tagged types, floating 
point types if there are signed zeros, and who knows for which other cases.

Thus it is generally a bad idea to override predefined operators for non-tagged 
types. If this is really necessary, then utmost care has to be applied 
everywhere such a type is used (e.g. as components of an array).

Reemergence has been introduced in the first place to avoid incompatibilities 
with Ada83.

Christoph Grein

> Its even worse than just that.  Now a "block compare" of any composite
> type
> that has a nontagged private type as a componant is questional because
> that
> comparison will utilize the predefined "=" of the private type even
> though
> the creator of the private type may have seen it proper to overridden
> it.
> 
> There was a thread, gosh, I guess less than two years ago where I was
> trying to
> argue that this was a disaster wrt generics and that reemergence of "="
> seemed
> to be a special case wrt the whole reemergence issue.   I now feel that
> the
> situation is very bad in general as opposed to being bad only wrt
> generics.
> 
> Does anyone think that it would be good for there to be a change in the
> language such that for private types, if a primative "=" returning
> boolean exists then it
> should be the "=" used as part of block compares and that the predefined
> one
> should not reemerge in generics?  This would not have been incompatible
> with
> Ada83, right?
> 
> I hope that the above is not perceved as rehashing old arguments - I do
> not
> remember the issues having been discussed exactly as above.
> 
> Vincent Marciante

Re: Overridability of _private_ predefined "=" [was Re: list strawman]

[Vincent Marciante]

> Christoph Grein wrote:
> Please, before going into further discussions about reemergence of predefined 
> operations and thinking about changing the language, read the corresponding 
> chapters in the AARM (the Annotated Ada Reference Manual), e.g. 
> AARM 4.5.2(24a-c).

I have read that.  
 
> With respect to "block compare",

I'm sorry, I think that I should have said 'usage of predefined "=" 
for composite types that have componants of a private type'.

> this is not possible for tagged types, floating 
> point types if there are signed zeros, and who knows for which other cases.

So, in addition to what Mark Lundquist wrote:

Mark Lundquist wrote:
> 
> >
> >    generic
> >       type Element is private;
> >       with function "=" (Left, Right : Element) return Boolean is <>;
> >    package Containers.Lists.Unbounded is
> >
> > This allows users who have unconventional ideas of equality to provide
> > their own routine, without requiring "normal" users to specify the
> > equality function explicitly.
> 
> Indeed it's a bug in Ada95 if the generic uses "=" without importing it
> explicitly.  Otherwise, an overridden "=" is not visible to the generic, and
> predefined equality "reemerges".

it seems to also be a bug in Ada95 if the generic uses predefined "=" of 
any composite types that have componants whose type is that of an
imported
private type. Right?
 
> Thus it is generally a bad idea to override predefined operators for non-tagged 
> types. If this is really necessary, then utmost care has to be applied 
> everywhere such a type is used (e.g. as components of an array).

This is why I find the situation to be so bad now.  A generic written
for Ada 83 that only imports a private type can not be made into a valid
Ada 95 one by simply transforming its spec by adding the importation of
"=" for that type;  Its body must also be analyzed and possibly changed
so as to use componant by componant comparison for any composite types
having the private type as a componant (or predefined "=" has to be
overridden for those composite types _and_ any other composite types the
have those composite types as componants.)

What was impossible (?) to do wrong in Ada 83 has now become a pitfall
in Ada 95. were by we have to dilligently follow the verbal guideline
that you just suggested. 

> Reemergence has been introduced in the first place to avoid incompatibilities 
> with Ada83.

I have read this but I have not seen the statement of the
incompatibilities that were avoided.  Can someone point me to that
information?

I must really be missing something (and I do want to understand what it
is if I am.)

>
>Christoph Grein
>
> Vincent Marciante wrote:
>> Its even worse than just that.  Now a "block compare" of any composite
>> type
>> that has a nontagged private type as a componant is questional because
>> that
>> comparison will utilize the predefined "=" of the private type even
>> though
>> the creator of the private type may have seen it proper to overridden
>> it.
>> 
>> There was a thread, gosh, I guess less than two years ago where I was
>> trying to
>> argue that this was a disaster wrt generics and that reemergence of "="
>> seemed
>> to be a special case wrt the whole reemergence issue.   I now feel that
>> the
>> situation is very bad in general as opposed to being bad only wrt
>> generics.
>> 
>> Does anyone think that it would be good for there to be a change in the
>> language such that for private types, if a primative "=" returning
>> boolean exists then it
>> should be the "=" used as part of block compares and that the predefined
>> one
>> should not reemerge in generics?  This would not have been incompatible
>> with
>> Ada83, right?
>> 
>> I hope that the above is not perceved as rehashing old arguments - I do
>> not
>> remember the issues having been discussed exactly as above.
>> 
>> Vincent Marciante

Re: Overridability of _private_ predefined "=" [was Re: list strawman]

[Nick Roberts]

"Vincent Marciante" <marciant_remove@li.net> wrote in message
news:3C49A5C4.51D6@li.net...

> ...
> This is why I find the situation to be so bad now.  A generic written
> for Ada 83 that only imports a private type can not be made into a valid
> Ada 95 one by simply transforming its spec by adding the importation of
> "=" for that type;  Its body must also be analyzed and possibly changed
> so as to use componant by componant comparison for any composite types
> having the private type as a componant (or predefined "=" has to be
> overridden for those composite types _and_ any other composite types the
> have those composite types as componants.)
>
> What was impossible (?) to do wrong in Ada 83 has now become a pitfall
> in Ada 95. were by we have to dilligently follow the verbal guideline
> that you just suggested.

AI-123 discusses this in some detail, and results (rev 12) in a corrigendum
which specifically compels language-defined types to be composable with
respect to equality (thus forcing them to be implemented either without
redefined equality or as tagged types). I smell a hint of hypocrisy here.

Personally, I completely agree with Vincent. Damn Ada 83 compatibility, and
damn implementation complexities: equality should always be composable; the
current state is plainly a potential source of 'nasty surprises'; the
language is purportedly supposed to avoid nasty surprises. But I am a small
voice.

--
Best wishes,
Nick Roberts