Re: Predefined equality, reemergence

["Adam Beneschan" <adam@irvine.com>]

Randy Brukardt wrote:
> "Adam Beneschan" <adam@irvine.com> wrote in message
> news:1144179981.495938.321410@e56g2000cwe.googlegroups.com...
> > I wrote:
> > > Hi, everyone,
> > >
> > > I'm having trouble understanding how the language rules about
> > > predefined equality, specifically 4.5.2(24), behave when the component
> > > type involved may be seen as "tagged" or "untagged" depending on
> > > whether you're inside an instance...........
> >
> > I mistakenly posted this before thoroughly checking the AI's.  I found
> > that AI-123 appears to address this question.  I've been looking over
> > this AI and I still don't know the answer to my question.
>
> I don't think AI-123 covers quite the same question.

Yeah, that one appears to apply only to language-defined types.

> But let me take a quick
> stab at it.
>
> If in doubt, generics in Ada follow a substitution model; that is, the
> result is the same if you wrote a non-generic equivalent. As such, I
> certainly would not expect "=" (or anything else for that matter) to behave
> differently depending on the location of the call. After all, you have a
> *real* subprogram "=" (as opposed to an implicit one), and that subprogram
> is going to have only one body of code.
>
> Now, it might be interesting to find language rules to back up this
> conclusion. :-) Personally, I find this as a case of Dewar's Rule (the
> standard doesn't mean to say anything stupid, even if the actual words can
> be read to come to a stupid conclusion). I'll leave finding wording as an
> exercise for someone else...

The reason I thought that "=" might mean something different in an
instance was because of the reemergence rules and how shared-code
generics (something that I know is a concern of yours) would be
difficult to implement without those rules.  For example,

    generic
        type INT is range <>;
    package Genpack is.....

Inside Genpack, anywhere you refer to "+" on objects of type INT, you
get the predefined addition operation even if "+" has been overridden
for the actual type.  Code sharing would be very difficult otherwise,
since you'd have to do an indirect call for every arithmetic
operation.

My first impression was that the same would apply to "=" on a generic
formal (untagged) private type---for shared-code generics, you'd want
the ability to compare two objects of your private type by doing a
straight bit comparison.  (Yeah, I know this causes problems for types
with holes in them.  So maybe this doesn't work anyway.)

Anyway, I did a little more digging, and found that the rule that
causes this reemergence is 12.5(8), which says, "In an instance, the
copy of such an implicit declaration declares a view of the predefined
operator of the actual type, even if this operator has been overridden
for the actual type".  This actually leads to some probably unintended
results if you compare objects of type T in the instance.  The rule
says that saying Left=Right in the instance, if both objects have type
T, means using the predefined equals operator, which is defined in
4.5.2.  Reading this section closely, it appears that if the actual
type for T is ACT, and ACT is a tagged record type, and there is a
user-defined primitive operator "=" on ACT, then: if ACT is a private
type, the predefined "=" is the user-defined "=" (4.5.2(15)), but if
ACT is not a private type, the user-defined "=" isn't used, and
instead we do a component-by-component equality operator as defined in
4.5.2(22-24).  Thus, you get *neither* the user-defined "=" *nor* the
straight bit comparison.  Is this really what was intended?  Should an
exception be made in 12.5(8) for "=" on generic formal private types?
Or at least when the actual type is tagged?

Finding this wording still doesn't strictly answer my question.
12.5(8) tells us what "=" means on objects of type T in an instance,
because it refers to an implicit declaration that gets copied.  But it
doesn't quite tell us what "=" means on a record that contains objects
of type T (i.e. Rec in my example)---I don't think 4.5.2 gives a clear
answer on this.  If "=" on objects of type T may mean something
different inside an instance than it does on objects of the actual
type outside the instance, then which "=" should be used to compare
components of type T, when we use "=" on objects of type Rec inside
the instance---and when we use "=" on objects of type Rec outside the
instance?

                                -- Adam