Re: Language lawyer question: Equality on 'Access attributes

[Robert A Duff <bobduff@shell01.TheWorld.com>]

adam@irvine.com (Adam Beneschan) writes:

> "Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<4LKdnRRNyv6AlmCiRVn-ig@comcast.com>...
> 
> > Adam Beneschan wrote:
> > > Given this code:
> > > 
> > > package Pak1 is
> > >     type Ptr1 is access all Integer;
> > >     X : aliased Integer;
> > >     Y : aliased Integer;
> > >     B : Boolean := X'Access = Y'Access;
> > > end Pak1;
> > > 
> > > GNAT gives me this error: "two access attributes cannot be compared
> > > directly / they must be converted to an explicit type for comparison".
> > 
> > GNAT is right.  This is a new instance of an issue that has been around 
> > since Ada 83.  In this case, the "general" access type returned by 
> > 'Access may have no relation to type Ptr1.  If you want to imagine that 
> > the implementation has other access all Integer types around, fine.  But 
> > technically, the Access attribute returns a type for which no comparison 
> > operations are defined.  
> 
> This isn't how I read the RM at all.  From what I can tell, from
> 3.10.2(24), X'Access does *not* necessarily return any sort of type
> implicitly defined by the language (for which no comparison operations
> would be defined).  The wording of this clause is:
> 
>    The type of X'Access is an access-to-object type, as determined by
>    the expected type.
> 
> The way I read this is that the type of X'Access is the expected type,
> which could be a program-defined type, which *would* have comparison
> operations defined for it.

This is a subtle area, so I could be missing something, but I agree with
your (Adam's) analysis here.  I think GNAT has a bug.

>...  This makes X'Access rather unique in this
> regard.  I believe that for any other construct that returns a value,
> one can determine what the type of the construct is (once it has been
> determined what declarations all the usage names pertain to) without
> knowing anything about the context in which the construct occurs.

Well, there are many cases where *context* is required to resolve
overloading.  For example:

    type Color is (Red);
    type Light is (Red, Amber, Green);

    procedure P(X: Light);

    P(Red); -- Same as P(Light'(Red));

This is why overload resolution in Ada requires a two pass algorithm, or
equivalent, whereas in most languages with overloading (C++ and Java,
for example), one bottom-up pass is sufficient.

I suspect the reason for the GNAT bug is that predefined "=" is
special-cased in the compiler.

You said above, "once it has been determined what declarations all the
usage names pertain to".  But that's sort of backward, since you can't
determine that without feeding information down from context (namely,
the type of the parameter X of procedure P).

Similarly, in:

    X: Some_Integer_Type := 123 + 456;

the type of each literal is determined by context.  (More precisely, the
type to which each literal should be implicitly converted.  Each literal
is converted separately; the "+" is that of Some_Integer_Type, not that
of _root_integer.)

>...  The
> type could be a universal type or some other unnamed type implicitly
> defined by the language.  But if my reading of 3.10.2(24) is correct,
> then this is *not* the case for X'Access: even if you know what X is,
> you don't know what the type of X'Access, out of context, because you
> don't know what the expected type is.  This would not be a problem
> that existed in Ada 83.
> 
> 
> > You can convert this type implicitly or 
> > explicitly to Ptr1, and the comparison will be okay:
> > 
> >    B : Boolean := Ptr1(X'Access) = Ptr1(Y'Access);
> 
> The above type conversions should be illegal, since 4.6(6) says that
> the expected type of the operand of a type conversion is "any type",
> but 3.10.2(2) requires that the expected type be "a single access
> type".  But qualified expressions would be legal, as follows:)

I agree.

>      B : Boolean := Ptr1'(X'Access) = Ptr1'(Y'Access);

In fact, just one qualification is probably enough to work around the
GNAT bug.

- Bob