Language lawyer question: Equality on 'Access attributes

Language lawyer question: Equality on 'Access attributes

[Adam Beneschan]

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

But I can't figure out why this should be an error.  Based on my
understanding of the language: The compiler needs to figure out
whether the interpretation of "X'Access = Y'Access" in which "="
denotes the equality operator implicitly defined for Ptr1 is an
acceptable interpretation (8.6(10-14)).  For a call to this "="
function, 6.4.1(3) says that the expected type for each argument is
Ptr1.  According to 3.10.2, X'Access and Y'Access do not have a
particular type out of context, but rather the types of these
constructs are determined by the expected type; when determining
whether these can be used as parameters to "=", the expected type is
Ptr1, and clearly it's legal to use X'Access or Y'Access in a
construct where the expected type is Ptr1.  So as far as I can tell,
this *is* an acceptable interpretation; and since there's only one "="
visible whose parameter types are access-to-integer, the requirement
of 8.6(30) is met that there be exactly one acceptable interpretation
of the function call, and thus this should be legal.  (If there were a
second access type, "type Ptr2 is access all integer", then B's
initialization expression would be ambiguous, since there would then
be two visible "=" operators for which the interpretation would be
acceptable.)  Note that the modified version of 3.10.2(2) in
AI95-00235 doesn't affect this analysis.

Is this analysis correct?  If not, where did I go wrong?  If I'm wrong
and GNAT is right, then could someone explain to me just how 8.6 and
3.10.2 are to be applied together when an 'Access attribute is used? 
The wording of the GNAT error message makes it appear to me that
GNAT's authors interpreted the RM as prohibiting this construct---but
I can't figure out where in the RM this would be prohibited.

                                     -- thanks, Adam

Re: Language lawyer question: Equality on 'Access attributes

[Robert I. Eachus]

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.  You can convert this type implicitly or 
explicitly to Ptr1, and the comparison will be okay:

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

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.

Why not "fix" the language so this problem doesn't occur?  It works 
correctly now, thank you very much!  You may think you "know" what the 
values in this case look like, but in the general case, the compiler 
needs to know what kind of pointer to generate for the 'Access 
attribute.  Go find any discussion of "fat pointers" vs. thin pointers, 
and for Ada a discussion of how some compilers will "pack" some access 
types to require less than the space for a full address.

In this case, the two 'Access attributes are probably going to be of the 
same type.  But if you are really using such a comparison in a real 
program, you don't want the Boolean value to depend on which version of 
which compiler you use.  So you have to tell the compiler which type, 
and implicitly which "=" operation to use for the comparison.

-- 
                                           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

Re: Language lawyer question: Equality on 'Access attributes

[Dmitry A. Kazakov]

On Thu, 08 Jan 2004 02:47:24 -0500, "Robert I. Eachus"
<rieachus@comcast.net> wrote:

>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.  You can convert this type implicitly or 
>explicitly to Ptr1, and the comparison will be okay:
>
>   B : Boolean := Ptr1(X'Access) = Ptr1(Y'Access);
>
>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.
>
>Why not "fix" the language so this problem doesn't occur?  It works 
>correctly now, thank you very much!  You may think you "know" what the 
>values in this case look like, but in the general case, the compiler 
>needs to know what kind of pointer to generate for the 'Access 
>attribute.  Go find any discussion of "fat pointers" vs. thin pointers, 
>and for Ada a discussion of how some compilers will "pack" some access 
>types to require less than the space for a full address.
>
>In this case, the two 'Access attributes are probably going to be of the 
>same type.  But if you are really using such a comparison in a real 
>program, you don't want the Boolean value to depend on which version of 
>which compiler you use.  So you have to tell the compiler which type, 
>and implicitly which "=" operation to use for the comparison.

One might think that X'Access is just another name for C's &X, but it
isn't quite so, as Robert Eachus explained.

And there is also the attribute 'Address:

with System;  use type System.Address;
...
declare
   X : Integer;
   Y : Integer;
   B : Boolean := X'Address = Y'Address;
      -- This is OK, the same type: System.Address

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Language lawyer question: Equality on 'Access attributes

[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

Re: Language lawyer question: Equality on 'Access attributes

[Robert A Duff]

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

Re: Language lawyer question: Equality on 'Access attributes

[Ze Administrator]

Robert A Duff wrote:
>>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.

I'd rather agree with Robert Eachus.  If 'X' and 'Y' are
both Integers, then X'Access obviously has to be a named
or anonymous type that is an access Integer.  Problem is,
there could be a dozen named types visible at that point
which are defined that way.  Some of them could be limited.
You are asking the compiler to arbitrarily pick any visible
non-limited 'access Integer' type, and use it for the comparison.

Re: Language lawyer question: Equality on 'Access attributes

[Robert A Duff]

Ze Administrator <groleau+news@freeshell.org> writes:

> Robert A Duff wrote:
> >>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.

First of all, I didn't write the above.  Note the number of ">"'s.

> I'd rather agree with Robert Eachus.  If 'X' and 'Y' are
> both Integers, then X'Access obviously has to be a named
> or anonymous type that is an access Integer.  Problem is,
> there could be a dozen named types visible at that point
> which are defined that way.

In which case, there would be many "=" operators visible,
and the expression would be ambiguous.

>...Some of them could be limited.

There's no such thing as a limited access type.  ;-)
Probably there should be, but that's another story!

> You are asking the compiler to arbitrarily pick any visible
> non-limited 'access Integer' type, and use it for the comparison.

No.  If there are more than one "=" visible that take access-to-integer,
then it would be ambiguous.  In the example given, there was only one
such "=".  The point is, resolution of "=" is just like any other
subprogram.

There's no question of "arbitrarily picking" a type.  For one thing, the
compiler is picking an "=" function, not a type.  And for another thing,
the compiler is *not* expected to think, "well, all those = operators
are basically the same thing anyway, so I'll just pick one arbitrarily".

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
subtle area -- I could be wrong.)  On the other hand, if you don't
*like* what the RM says, please explain why "=" should behave
differently from other subprograms.

Note that various features *do* behave differently.  For example, as was
pointed out by somebody, there's a special rule for type conversions.
But "=" is just a function -- sometimes predefined, sometimes user
defined, so what matters is how many are visible, with what parameter
and result types (and, I claim, that's probably a good thing).

- Bob

Re: Language lawyer question: Equality on 'Access attributes

[Ze Administrator]

Robert A Duff wrote:
> There's no such thing as a limited access type.  ;-)
> Probably there should be, but that's another story!

   type IA is limited private;

private

   type IA is access Integer;

Re: Language lawyer question: Equality on 'Access attributes

[Robert A Duff]

Ze Administrator <groleau+news@freeshell.org> writes:

> Robert A Duff wrote:
> > There's no such thing as a limited access type.  ;-)
> > Probably there should be, but that's another story!
> 
>    type IA is limited private;
> 
> private
> 
>    type IA is access Integer;

OK, sorry, I didn't understand what you meant.  Yes, of course, if
somebody has visibility (only) on the limited private type, then it does
not implicitly define "=", so there's no "=" to call (for that type).

The issue is not (directly) which types are visible, but which "="
functions are visible (either implicitly declared by type declarations,
or explicitly declared as functions).

Type IA above is not "really" limited, because it can be copied.
For parameters, it is passed by copy, for example.

- Bob

Re: Language lawyer question: Equality on 'Access attributes

[Ze Administrator]

Robert A Duff wrote:
> The issue is not (directly) which types are visible, but which "="
> functions are visible (either implicitly declared by type declarations,
> or explicitly declared as functions).

If the types are visible, and 'use' or 'use type'
has been used, then "=" is visible.

Re: Language lawyer question: Equality on 'Access attributes

[Ze Administrator]

Robert A Duff wrote:
> No.  If there are more than one "=" visible that take access-to-integer,
> then it would be ambiguous.  In the example given, there was only one
> such "=".  The point is, resolution of "=" is just like any other
> subprogram.

There was no definition of "=" in the example,
nor was there a type definition to imply one.

> 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 could go to groups.google.com but arguing is more fun.

Re: Language lawyer question: Equality on 'Access attributes

[Robert A Duff]

Ze Administrator <groleau+news@freeshell.org> writes:

> Robert A Duff wrote:
> > No.  If there are more than one "=" visible that take access-to-integer,
> > then it would be ambiguous.  In the example given, there was only one
> > such "=".  The point is, resolution of "=" is just like any other
> > subprogram.
> 
> There was no definition of "=" in the example,
> nor was there a type definition to imply one.

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.

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

;-)

- Bob

Re: Language lawyer question: Equality on 'Access attributes

[Ze Administrator]

Robert A Duff wrote:
> Ze Administrator <groleau+news@freeshell.org> writes:
>>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.

Well, I agreed with Eachus's argument at the time,
but I am no longer quite sure what it was.

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

I'm going to have to give up arguing for an unknown
amount of time.  The "world's most advanced operating
system" is not behaving very well, and the vendor's
tech support has apparently been taken over by Microsoft,
because their only suggestion is wipe the disk and re-install.
(which I did only a week ago, and it has never worked right).

10.1.5 was the best-behaved system I've ever used.
10.3.2 so far is the worst (yes, even worse than any Windows).
AdaOS, where are you?  :-)

Re: Language lawyer question: Equality on 'Access attributes

[Marin David Condic]

Of course just because its in Ada doesn't mean its going to be of high 
quality. Just that you'll eliminate the most obvious and easiest to 
catch errors. Operating systems can be very sensitive to available 
resources, timing, prior states, etc. None of those things can be fixed 
by a programming language - only by good design.

MDC

Ze Administrator wrote:
> 
> 10.1.5 was the best-behaved system I've ever used.
> 10.3.2 so far is the worst (yes, even worse than any Windows).
> AdaOS, where are you?  :-)


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Language lawyer question: Equality on 'Access attributes

[Robert I. Eachus]

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

Re: Language lawyer question: Equality on 'Access attributes

[Robert A Duff]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> 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;

I guess all you did was erase the "all"?

> Is your position Bob, that this version is illegal?

Yes.  There's only one "=" of interest here.  So the expected type of
X'Access is Ptr1, which is not a general access type.  You can't do
X'Access returning a non-general access type.

In other words, overload resolution works the same as in the other
example, but there's a legality rule being violated.

>...Now there is no
> visible general access type, or at least none that the user can see.  

Well, I'm presuming you're showing me the whole example!  If there are
some other "=" operators visible that I can't see, then who knows?

> What is the expected type of "=" above?

Boolean.  Not sure what you mean...

>...Can we use the fact that
> anonymous access types don't have equality operators.

I don't see any anonymous access types in the example.
But yes, if there were, the "=" operators that are visible
would not include ones for those anonymous types.
And resolution would proceed accordingly.

> 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?

Yes.

>...  And if so does it make a
> construct illegal, or rule it out of consideration.

It just tells us which implicit declarations exist.
That information affects overload resolution.

- Bob

Re: Language lawyer question: Equality on 'Access attributes

[Robert I. Eachus]

Robert A Duff wrote:

> I guess all you did was erase the "all"?

Yep.

>>Is your position Bob, that this version is illegal?
>  
> Yes.  There's only one "=" of interest here.  So the expected type of
> X'Access is Ptr1, which is not a general access type.  You can't do
> X'Access returning a non-general access type.
> 
> In other words, overload resolution works the same as in the other
> example, but there's a legality rule being violated.
> 
>>...Now there is no
>>visible general access type, or at least none that the user can see.  
> 
> Well, I'm presuming you're showing me the whole example!  If there are
> some other "=" operators visible that I can't see, then who knows?

I think I am now convinced that GNAT has a bug.  The potential problem 
with anonymous access types I thought was the problem can occur, but 
only if declarations like:

function "=" (Left : A_Ptr; Right : access A) return Boolean;

...appeared somewhere in GNAT. I think that any such declarations 
written by a user are candidates for pathologies, but if an 
implementation does it, I'd have to call it malicious.

A similar example is single character attribute names.  They can 
seriously mess up the overload resolution code.  But of course, 
implementors deal with that problem by just never declaring single 
character attribute names.

>>What is the expected type of "=" above?
> 
> Boolean.  Not sure what you mean...

That is the expected result type.  What is the expected type of the 
parameters?  As I said, I am now convinced that if there is another 
candidate "=" declaration, possibly defined by the implementation, then 
that counts as a bug.

> I don't see any anonymous access types in the example.
> But yes, if there were, the "=" operators that are visible
> would not include ones for those anonymous types.
> And resolution would proceed accordingly.

>>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?
>  
> Yes.
> 
I'm still a bit concerned about this, since the two cases combined in 
4.5.2(6) are significantly different.  (The rule about limited types 
applies to both truly limited types and limited views.  However 
anonymous access types never have re-emerging "=" operators.  But I now 
think that since you can't pass an anonymous access type as a generic 
formal, there is no real harm done.

>>...  And if so does it make a
>>construct illegal, or rule it out of consideration.
>  
> It just tells us which implicit declarations exist.
> That information affects overload resolution.

My concern was really that it applies to limited views. Sometimes you do 
have "=" operations for limited types that have to be considered in 
overload contexts.  But I am now convinced, as I said above, that views 
of anonymous access types which have equality operations are 
pathological.  (I could probably be talked into voting for a change 
which eliminated the pathology, but I now think it only makes sense as a 
part of the other Ada OY changes--if the changes otherwise make it 
easier for users to shoot themselves in the foot.

-- 
                                           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

Re: Language lawyer question: Equality on 'Access attributes

[Ze Administrator]

Robert I. Eachus wrote:
> I think I am now convinced that GNAT has a bug.  

Well, you have just disillusioned your loyal follower(s).

:-)

But getting rid of illusions is a Good Thing, no?

Re: Language lawyer question: Equality on 'Access attributes

[Robert I. Eachus]

Ze Administrator wrote:

> Robert I. Eachus wrote:
> 
>> I think I am now convinced that GNAT has a bug.  
> 
> 
> Well, you have just disillusioned your loyal follower(s).
> 
> :-)
> 
> But getting rid of illusions is a Good Thing, no?

Especially that one.  ANY member of the ARG will be glad to tell you if 
asked that for many problems that do need to be addressed by the ARG, 
the ARG as a whole will get it wrong several times before we get it 
right. In fact for a while it used to be common for an AI to read 
approved 10-0, letter ballot requested, letter ballot failed 0-9-2, 
reconsidered.

And for the hard issues this would happen several times.  I don't know 
what the record is for number of times an AI has be passed then 
reconsidered.  As far as I am concerned thought AI-315 for Ada 83 
(Exceptions and Optimization) was probably the record in terms of the 
number of times it was considered.  We considered it almost every 
meeting, made some progress toward a solution, then sent it back for a 
rewrite and reconsideration.  What was the problem that was so 
impossible to solve?  Easy consider the following program fragment:

  X, Y : Integer;
  ...
    declare
      Junk: Integer;
    begin
      Text_IO.Get(X);
      Text_IO.Get(Y);
      Junk := X * Y;
    exception
      when others => Text_IO.Put_Line(" Product too large.");
    end;
  ...

In Ada 83 we couldn't figure out any way to require compilers to 
actually print the message if X * Y > Integer'Last, without major 
surgery.  Since the compiler vendors were all aware of the issue, no one 
was going to get that aggressive with optimizations until we figured it out.

The problem was finally fixed in Ada 95 by doing the major surgery.  The 
effect of a program is defined in terms of external events.  So even 
though the value of Junk is never read, you have to do the 
multiplication to figure out whether or not to print the message.  (And 
in fact, in Ada 95 you don't have to assign the result of the 
multiplication to Junk, or even allocate space for it.)

In the case at hand, I originally thought there was, among other things, 
an issue with anonymous access types.  The issue is there, but on 
further examination it turns out to be a pathology.  Hmmm. I thought of 
an even more bizzarre pathological case involving return-by-reference 
functions.  But I probably should have buried that thought before it got 
this far.  In fact, at this point the ARG is pretty much convinced that 
return by reference functions, as such, were probably a bad idea to 
begin with. ;-)

-- 
                                           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

Re: Language lawyer question: Equality on 'Access attributes

[Adam Beneschan]

Ze Administrator <groleau+news@freeshell.org> wrote in message news:<6bSdnYBKy_diPGCi4p2dnA@gbronline.com>...
> Robert A Duff wrote:
> >>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.
> 
> I'd rather agree with Robert Eachus.  If 'X' and 'Y' are
> both Integers, then X'Access obviously has to be a named
> or anonymous type that is an access Integer.  Problem is,
> there could be a dozen named types visible at that point
> which are defined that way.  Some of them could be limited.
> You are asking the compiler to arbitrarily pick any visible
> non-limited 'access Integer' type, and use it for the comparison.

No, I'm not.  If there are a dozen named access-to-integer types
directly visible at that point (which would mean that their "="
operators are also visible), the RM rules clearly say that "=" would
be ambiguous.  I think I briefly touched on that situation in my
original post.  The question is, what should happen when only one such
"=" operator is a possibility.

                                 -- Adam

Re: Language lawyer question: Equality on 'Access attributes

[Ze Administrator]

Adam Beneschan wrote:
> No, I'm not.  If there are a dozen named access-to-integer types
> directly visible at that point (which would mean that their "="
> operators are also visible), the RM rules clearly say that "=" would
> be ambiguous.  I think I briefly touched on that situation in my
> original post.  The question is, what should happen when only one such
> "=" operator is a possibility.

Every construct that implies a type without naming it
effectively declares an anonymous type, right?  Can any
two constructs 'declare' the same anonymous type?

Re: Language lawyer question: Equality on 'Access attributes

[Dmitry A. Kazakov]

On Thu, 08 Jan 2004 23:10:44 -0500, Ze Administrator
<groleau+news@freeshell.org> wrote:

>Adam Beneschan wrote:
>> No, I'm not.  If there are a dozen named access-to-integer types
>> directly visible at that point (which would mean that their "="
>> operators are also visible), the RM rules clearly say that "=" would
>> be ambiguous.  I think I briefly touched on that situation in my
>> original post.  The question is, what should happen when only one such
>> "=" operator is a possibility.
>
>Every construct that implies a type without naming it
>effectively declares an anonymous type, right?  Can any
>two constructs 'declare' the same anonymous type?

No, but it is not that simple, because anonymous types aren't matched
by names. This works fine with unary operations, but might be
problematic with n-ary ones (like = is). It could be easy to do if ARM
would define sort of "universal access type" as it does for integers.
But this not the case. Annex K only states:

"...The type of X�Access is an access-to-object type, as determined by
the expected type. The expected type shall be a general access type.
See 3.10.2."

What is the "expected type" in the case of X'Access = Y'Access? There
is no one! So I think that GNAT formally does not contradict the
standard.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Language lawyer question: Equality on 'Access attributes

[Robert A Duff]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> What is the "expected type" in the case of X'Access = Y'Access? There
> is no one! So I think that GNAT formally does not contradict the
> standard.

The expected type is the type of the formal parameter of "=".
There is only one such "=" of interest, and its formal parameter
has type Ptr1.

- Bob

Re: Language lawyer question: Equality on 'Access attributes

[Dmitry A. Kazakov]

Robert A Duff wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
> 
>> What is the "expected type" in the case of X'Access = Y'Access? There
>> is no one! So I think that GNAT formally does not contradict the
>> standard.
> 
> The expected type is the type of the formal parameter of "=".
> There is only one such "=" of interest, and its formal parameter
> has type Ptr1.

Just summarizing...

Your point is that the compiler should consider all visible types and all
visible "=" to crunch X'Access = Y'Access. Then X'Access = Y'Access is
illegal if there is no visible named access types. Then provided:

type A is tagged null record;
type A_Ptr is access all A;
function "=" (Left : A_Ptr; Right : access A) return Boolean;
X : aliased A;
Y : aliased A;

X'Access = Y'Access -- is ambiguous

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Language lawyer question: Equality on 'Access attributes

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

> Just summarizing...
> 
> Your point is that the compiler should consider all visible types and all
> visible "=" to crunch X'Access = Y'Access. Then X'Access = Y'Access is
> illegal if there is no visible named access types. Then provided:
> 
> type A is tagged null record;
> type A_Ptr is access all A;
> function "=" (Left : A_Ptr; Right : access A) return Boolean;
> X : aliased A;
> Y : aliased A;
> 
> X'Access = Y'Access -- is ambiguous

That I certainly agree with.  But there are two further issues that MAY 
apply in the actual example.  The first is that predefined operators 
don't need to be visible to be considered by overload resolution. 
(Usually there are other overload resolution rules that result in 
interpretations using invisible operators being eliminated.)  The second 
is that the rule that anonymous access types don't have a predefined "=" 
operator is not a syntax or overload resolution rule.

The combination of the above can result in an invisible anonymouns 
access Integer type creating an overload interpretation that is illegal 
rather than ignored.  If RM 4.5.2(6) should be considered as a 
overloading rule, that eliminates potential problems in the original 
case.  (However, the part of the 4.5.2(6) rule for limited types 
shouldn't become a name resolution rule.  The rules for re-emergence of 
predefined equality for limited types are somewhat confusing, but 
changing them might be worse.)

In any case, your example would still be illegal, since the user defined 
"=" is visible.

-- 
                                           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

Re: Language lawyer question: Equality on 'Access attributes

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Just summarizing...
> 
> Your point is that the compiler should consider all visible types and all
> visible "=" to crunch X'Access = Y'Access. Then X'Access = Y'Access is
> illegal if there is no visible named access types. Then provided:
> 
> type A is tagged null record;
> type A_Ptr is access all A;
> function "=" (Left : A_Ptr; Right : access A) return Boolean;
> X : aliased A;
> Y : aliased A;
> 
> X'Access = Y'Access -- is ambiguous

I believe the above is correct.

- Bob

Re: Language lawyer question: Equality on 'Access attributes

[Robert A Duff]

Ze Administrator <groleau+news@freeshell.org> writes:

> Adam Beneschan wrote:
> > No, I'm not.  If there are a dozen named access-to-integer types
> > directly visible at that point (which would mean that their "="
> > operators are also visible), the RM rules clearly say that "=" would
> > be ambiguous.  I think I briefly touched on that situation in my
> > original post.  The question is, what should happen when only one such
> > "=" operator is a possibility.
> 
> Every construct that implies a type without naming it
> effectively declares an anonymous type, right?

No... I don't remember any such statement in the RM.
(I *wrote* large parts of the RM, so I *might* know what I'm talking
about.  Or I might have forgotten what I wrote.  ;-))

>...Can any
> two constructs 'declare' the same anonymous type?

No.

But anonymous access types are declared by access definitions, not
uses of 'Access.

- Bob

Re: Language lawyer question: Equality on 'Access attributes

[Robert I. Eachus]

Robert A Duff wrote:

> But anonymous access types are declared by access definitions, not
> uses of 'Access.

Correct, but slightly misleading.  An access definition in a parameter 
or a discriminant declaration creates an anonymous access type.  In a 
type declaration, of course, it creates a non-anonymous access type. 
(I'm becoming more and more convinced that this needs a BI.  I think the 
presence of anonymous access types can cause the example to be illegal. 
  But I am not happy with that position, since the existance of 
anonymous access types shouldn't affect legality in this case. I think 
that was the intent of not having operations for anonymous access types. 
  I just don't think the RM currently covers all the bases.)

-- 
                                           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

Re: Language lawyer question: Equality on 'Access attributes

[tmoran]

>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.
  Data point: Both ObjectAda and Janus compile it with no complaints.

Re: Language lawyer question: Equality on 'Access attributes

[Robert A Duff]

tmoran@acm.org writes:

> >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.
>   Data point: Both ObjectAda and Janus compile it with no complaints.

Interesting.  Note that the ObjectAda front end is the front end
that my company (SofCheck, Inc) sells!  Honest, I didn't try it
before posting my opinion.  ;-)

- Bob

Re: Language lawyer question: Equality on 'Access attributes

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcc1xqa1fmj.fsf@shell01.TheWorld.com...
> adam@irvine.com (Adam Beneschan) writes:
> > 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.

I agree with Bob and Adam. This isn't a very important bug (most such
expressions would be ambigious), but it is a bug. Note that when we were
working on AI-235, we found that compilers varied wildly in their handling
of 'Access. No one actually implemented the RM language (which is why it was
changed). But I'd be very suspious of using any compiler's behavior on
'Access tests as somehow correct.

In any case, Adam seems to be under some misconception about resolution in
Ada. He continuely seems surprised about some case or other that makes it
hard. While it is well-defined, implementing it correctly is very, very
difficult. (Which is why the ARG has tried to change it as little as
possible for Ada 200Y - we don't want to break existing code in subtle
ways.) That's because of all of the bizarre cases where you have to get
information from both context and from the names, and somehow try to find a
single unique interpretation. A(1) := B(1); can be a real mess to resolve if
there are a number of A and B functions: parameterless returning arrays;
parameterless returning access-to-array; and with one parameter returning a
component type. It easy to construct cases with many functions of each name,
but only one combination that actually works. Yuk!

                           Randy.

Re: Language lawyer question: Equality on 'Access attributes

[Adam Beneschan]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wcc1xqa1fmj.fsf@shell01.TheWorld.com>...

> >...  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));

That's why I included the parenthesized phrase, "once it has been
determined what declarations the usage names pertain to".  Once you've
determined that the name "Red" pertains to the second declaration of
Red, and not the first one, you then know what the type of "Red" is. 
(Of course, you need the context to determine which declaration is the
correct one.)  This isn't the case for X'Access: even if you know what
declaration X refers to, you still don't know waht type X'Access is.

However, I was wrong when I thought that 'Access was unique here. 
There are other cases where the type of a construct cannot be
determined without context: namely, "null", character literals, and
string literals.


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

I have to admit that while I think my assertion is true, it's pretty
abstract.  It probably requires one to think backwards from how a
practical programmer, or a compiler, would think when trying to
determine the meaning of an Ada statement like that.

                                      -- Adam

Re: Language lawyer question: Equality on 'Access attributes

[Robert A Duff]

adam@irvine.com (Adam Beneschan) writes:

> I have to admit that while I think my assertion is true,...

Your assertion is true.

>... it's pretty
> abstract.  It probably requires one to think backwards from how a
> practical programmer, or a compiler, would think when trying to
> determine the meaning of an Ada statement like that.

I think it's backward from how the compiler "thinks".  But that's OK.
As to how the "practical programmer" thinks, well, I guess it's safe
to just write what makes sense, and correct it if the compiler cries
"ambiguous".  Sounds sloppy, but it's not, really.  The language rules
are set up so you won't likely get into trouble (i.e. run-time
trouble).

- Bob

Re: Language lawyer question: Equality on 'Access attributes

[Robert I. Eachus]

Robert A Duff wrote:

> 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.

And I think that GNAT is right, which is why we have the ARG. ;-)  But 
in this case I think this is a low priority AI, and if one is created, I 
would vote for whatever it says just to close the issue.

The technical question is how many "=" operations could apply in this 
case.  My contention was that there are at least two, one associated 
with the 'Access attributes (actually I think there is one for each 
attribute) and one declared by the user.

It is much easier to see why there is an issue if X is on the stack, and 
Y is in a user managed heap, or even just one object at library level, 
and one on the stack.  (That way one value has a nested accessability 
level to be checked, and the other has a static lifetime longer than the 
program.)  You could argue that those pointers can never compare 
equal--and I'd agree.  But the compiler conceptually has two objects of 
different types.  If you want the comparison to occur, you can assign 
one or both to a local access variable, which will "scrub off" the 
access level information.

Yes, the compiler can be smart about this and conclude that if the two 
objects have different accessability levels, they can't compare equal. 
But normally in Ada we prefer to have the compiler tell you there is a 
potential issue rather than have different compilers do different 
things.  (Which is why if this becomes an AI, I will vote back the 
consensus, whatever it is.  It is more important to have a consistent 
language than to "win" language lawyer debates in the ARG. ;-)

-- 
                                           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

Re: Language lawyer question: Equality on 'Access attributes

[Randy Brukardt]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:XridndndEa-m2mOiRVn-hQ@comcast.com...
...
> The technical question is how many "=" operations could apply in this
> case.  My contention was that there are at least two, one associated
> with the 'Access attributes (actually I think there is one for each
> attribute) and one declared by the user.

Huh? There is nothing in the RM about types being declared by 'Access. The
only way to get an anonymous access type is via an access_definition, as in
a parameter. And anonymous access types don't even have their own "=", see
4.5.2(6) "...for every type T that is not limited, and is not an anonymous
access type."

Ada 200Y probably will change this slightly; we've spent a lot of ARG time
looking at this area because we want to expand the places that anonymous
access types can be used.

In any case, in the original example, there is only one "=", so Adam is
right. In Ada 200Y, as currently envisioned, I think that this would be
ambiguous (because the universal "=" would also be a possibility). But
that's in the future and could change.

                  Randy.

Re: Language lawyer question: Equality on 'Access attributes

[Robert I. Eachus]

Randy Brukardt wrote:

> "Robert I. Eachus" <rieachus@comcast.net> wrote in message
> news:XridndndEa-m2mOiRVn-hQ@comcast.com...
> ...
> 
>>The technical question is how many "=" operations could apply in this
>>case.  My contention was that there are at least two, one associated
>>with the 'Access attributes (actually I think there is one for each
>>attribute) and one declared by the user.
> 
> Huh? There is nothing in the RM about types being declared by 'Access. The
> only way to get an anonymous access type is via an access_definition, as in
> a parameter. And anonymous access types don't even have their own "=", see
> 4.5.2(6) "...for every type T that is not limited, and is not an anonymous
> access type."

Yeah, I goofed when I wrote the part you quoted.  (I should never play 
language lawyer after midnight.)  But I am still convinced that there is 
an issue here.  If there are anonymous access Integer types around, it 
is not clear to me that they can be ignored during overload resolution.

Let me reiterate that I am not saying that a compiler that concludes the 
example program is legal are wrong.  Far from it.  But I am saying that 
   GNAT's interpretation may also be correct, and it may depend on 
whether or not the implementation (or the user) defines an access 
Integer parameter somewhere.

Visibility of predefined "=" (and other predefined operators) is a best 
described by first pointing at RM 8.3(29) (which is a note): "Not all 
contexts where an identifier, character_literal, or operator_symbol are 
allowed require visibility of a corresponding declaration. Contexts 
where visibility is not required are identified by using one of these 
three syntactic categories directly in a syntax rule, rather than using 
direct_name or selector_name."

Now look at RM 4.5(1..7):   "The language defines the following six 
categories of operators (given in order of increasing precedence). The 
corresponding operator_symbols, and only those, can be used as 
designators in declarations of functions for user-defined operators..."

A similar problem occured in Ada83 with "for I in -1..10;" (or other 
similar constructs).  Even if there was only one predefined integer 
type, the existance of Count in Text_IO made the "-" operator ambiguous, 
even if there was no with for Text_IO.  This issue was fixed in Ada 95 
by 8.6(29).

I certainly agree that my interpretation is not one that I am 
comfortable with.  I am also not sure that I like all of the 
ramifications of the other/majority interpretation.

 > Ada 200Y probably will change this slightly; we've spent a lot of ARG 
 > time looking at this area because we want to expand the places that
 > anonymous access types can be used.

It is probably not worth a separate BI at this point, but fixing the 
relevant wording should be rolled into Ada0Y.  (I've never liked the 
wording of RM 8.6 (20..25) anyway. ;-)

-- 
                                           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

Re: Language lawyer question: Equality on 'Access attributes

[Robert A Duff]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> Dennis Lee Bieber fed this fish to the penguins on Thursday 08 January 
> 2004 00:30 am:
> 
> 
> > 
> >         3.2.1(7) (at least, in my copy of the reference)
> >
> 
>         Hmmm, surprising -- no comments following this reference, but lots 
> still working on the other parts... are my posts even getting out 
> beyond Earthlink/Netcom?

Yes, I saw your previous post.  3.2.1(7) mentions the idea of anonymous
types, but it doesn't say when they get declared.  You can search the RM
to find them all, or you can look at 3.2.1(7.a) in the AARM.  Anyway,
'Access does *not* declare any anonymous types.  Anonymous access types
are declared when you say "access T" as a parameter or discriminant
type.  But those have nothing to do with the example we're discussing.

- Bob

Re: Language lawyer question: Equality on 'Access attributes

[Randy Brukardt]

"Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message
news:l7v1d1-n33.ln1@beastie.ix.netcom.com...
> Dennis Lee Bieber fed this fish to the penguins on Thursday 08 January
> 2004 00:30 am:

> >         3.2.1(7) (at least, in my copy of the reference)
> >
>
>         Hmmm, surprising -- no comments following this reference, but lots
> still working on the other parts... are my posts even getting out
> beyond Earthlink/Netcom?

I see *this*  message. As to why I only answered the other one -- one answer
per thread is about all I have time for...

               Randy.

Re: Language lawyer question: Equality on 'Access attributes

[christoph.grein]

RM 3.10.2(2) ...Access...the expected type shall be a single access type...

RM 8.6(27) When the expected type...is required to be a single type...shall be 
determinable solely from the context...shall not be the operand of a 
type_conversion.

Therefore:

	B: Boolean :=    X'Access  = Y'Access;  -- illegal
	B: Boolean := T (X'Access) = Y'Access;  -- illegal
	B: Boolean := T'(X'Access) = Y'Access;  --   legal

Re: Language lawyer question: Equality on 'Access attributes

[christoph.grein]

> original post.  The question is, what should happen when only one such
> "=" operator is a possibility.

AARM 8.6(27.a) ...The resason for these rules is that the compiler will not have 
to search "everywhere"...