Re: Language lawyer question: Equality on 'Access attributes

["Robert I. Eachus" <rieachus@comcast.net>]

Robert A Duff wrote:

> The example was:
> 
> package Pak1 is
>     type Ptr1 is access all Integer;
>     X : aliased Integer;
>     Y : aliased Integer;
>     B : Boolean := X'Access = Y'Access;
> end Pak1;
>
> and the declaration of Ptr1 causes an implicit declaration of "=".
> 
> If that is the *only* visible "=" on access types, then I claim the
> above is legal.
> 
>>>If you don't believe this is what the RM says (which was the original
>>>question), you should quote chapter and verse.  (I admit that this is a
>>
>>I don't recall the reference Robert Eachus used.
> 
> 
> I don't think he quoted any RM paragraphs.  I didn't either.
> But Adam did, and I agreed with his analysis.

Actually I think I quoted a section, but didn't reference a paragraph. 
But that is irrelevent.  This is the classic case in the ARG where both 
sides can construct a proof/ramification of to why their answer is 
correct.  But if the RM leads to a contradiction like that, a binding 
interpretation is required to clean it up.

>>I could go to groups.google.com but arguing is more fun.

Isn't that attitude a requirement for the ARG (along with not taking 
anything said when discussing an AI personally? ;-)

So let me take the example and modify it a bit:

  package Pak1 is
      type Ptr1 is access Integer;
      X : aliased Integer;
      Y : aliased Integer;
      B : Boolean := X'Access = Y'Access;
  end Pak1;

Is your position Bob, that this version is illegal?  Now there is no 
visible general access type, or at least none that the user can see.  My 
read is that there is no difference between the two examples. 3.10.2(2) 
says: "For an attribute_reference with attribute_designator Access (or 
Unchecked_Access -- see 13.10), the expected type shall be a single 
access type; the prefix of such an attribute_reference is never 
interpreted as an implicit_dereference."

What is the expected type of "=" above? Can we use the fact that 
anonymous access types don't have equality operators.  (See 3.10.2(34), 
but note that it is a note.  However, it refers to 4.5.2(6), which is 
not a note: "The equality operators are predefined for every specific 
type T that is not limited, and not an anonymous access type, with the 
following specifications:")

Now off to chapter 8, since 3.10.2(2) was a name resolution rule. ;-) 
First look at 8.6(2): "Certain rules of the language (the Name 
Resolution Rules) are considered ``overloading rules''. If a possible 
interpretation violates an overloading rule, it is assumed not to be the 
intended interpretation; some other possible interpretation is assumed 
to be the actual interpretation. On the other hand, violations of 
non-overloading rules do not affect which interpretation is chosen; 
instead, they cause the construct to be illegal. To be legal, there 
usually has to be exactly one acceptable interpretation of a construct 
that is a ``complete context'', not counting any nested complete contexts."

Whew!  First, 3.10.2(2) was a Name Resolution Rule, so it can't make a 
construct illegal.  However, 4.5.2(6) is "Static Semantics."  Can it be 
considered in a name resolution context?  And if so does it make a 
construct illegal, or rule it out of consideration.  (My read of course, 
is that 4.5.2(6) is not an overloading rule.)  But there is more...

Look at 8.6(22-25), or better yet don't.  I always seem to get a 
headache when I do: ;-)

    "* If the expected type for a construct is a specific type T, then 
the type of the construct shall resolve either to T, or:

     * to T'Class; or

     * to a universal type that covers T; or

     * when T is an anonymous access type (see 3.10) with designated 
type D, to an access-to-variable type whose designated type is D'Class 
or is covered by D."

Let's do the matching, and go back to the original example.  T would 
have to be Ptr1, for which there is an "=" operation, and D is Integer. 
  So the legal types under this rule are Ptr1 by paragraph 21, 
Ptr1'Class by paragraph 23, and paragraphs 24 and 25 do NOT apply.

Notice that paragraph 25 would have made it clear that this worked, if 
the expected type was the anonymous access type, and the actual type was 
Ptr1.  But this situation is the exact reverse of that.  Since there are 
no equality operations for anonymous access types, the expected type has 
to be a type for which an equality operation is defined.

So I conclude that this is not a complete context in which an anonymous 
access type can appear in place of a specific type, whether there is one 
visible potential access to variable type, none, or several.

I don't see much real need for this case to "work" and I would be 
opposed to a major change to the overloading rules to make it work.  But 
changing the places where an anonymous access type can appear when the 
expected type is an access to variable type would, to me, not be a big 
deal.  I do think that such a change should be a binding interpretation, 
probably to add a paragraph after 8.6(25).
-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush