Re: Language lawyer question: Equality on 'Access attributes

[adam@irvine.com (Adam Beneschan)]

"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 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.  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:)

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

In fact, GNAT (correctly) disallows the type conversions, giving this
message: 

    argument of conversion cannot be access
    use qualified expression instead

and accepts the expression with qualified expressions.  

> or:
> 
>    Temp: Ptr1 := X'Access;
>    B: Boolean := Temp = Y'Access;
> 
> I haven't tested this code, it is very late at night.  But GNAT is being 
> helpful in their error message.

Not really.  If the error message says "they must be converted to an
explicit type", and converting it to an explicit type turns out to
produce another error message, then the first error message isn't
really helpful.  

> Why not "fix" the language so this problem doesn't occur?  It works 
> correctly now, thank you very much!  

I actually don't care whether "X'Access = Y'Access" is legal.  If it's
illegal, I don't think the language needs to be fixed to make it
legal---but I do believe that the language would need to be fixed to
clear up the wording, since the wording of the RM seems to make it
appear that the comparison should be legal (if not ambiguous), and the
RM doesn't seem to say anything at all about 'Access returning a
"special" type for which no comparisons are defined.  Your arguments
about why "X'Access = Y'Access" should be illegal make sense, but
they're beside the point, since my question is about what the RM
actually says rather than about what makes sense.

But if there's something in the RM I've missed, I'd appreciate knowing about it.
 
If this is becoming an issue of whether the RM's wording has the
intended result or not, then I'll copy the thread to Ada-Comment.

                                -- Adam