comp.lang.ada
 help / color / mirror / Atom feed
From: "Robert I. Eachus" <rieachus@comcast.net>
Subject: Re: Language lawyer question: Equality on 'Access attributes
Date: Sun, 11 Jan 2004 09:27:50 -0500
Date: 2004-01-11T09:27:50-05:00	[thread overview]
Message-ID: <Fv-dnZCHh5v6wJzd4p2dnA@comcast.com> (raw)
In-Reply-To: <wccad4vipt1.fsf@shell01.TheWorld.com>

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




  reply	other threads:[~2004-01-11 14:27 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-08  2:05 Language lawyer question: Equality on 'Access attributes Adam Beneschan
2004-01-08  7:47 ` Robert I. Eachus
2004-01-08 11:07   ` Dmitry A. Kazakov
2004-01-08 17:18   ` Adam Beneschan
2004-01-08 18:04     ` Robert A Duff
2004-01-08 18:31       ` Ze Administrator
2004-01-08 21:04         ` Robert A Duff
2004-01-09  4:02           ` Ze Administrator
2004-01-09 23:02             ` Robert A Duff
2004-01-10  2:56               ` Ze Administrator
2004-01-09  4:06           ` Ze Administrator
2004-01-09 23:05             ` Robert A Duff
2004-01-10  3:03               ` Ze Administrator
2004-01-10 13:47                 ` Marin David Condic
2004-01-10  7:19               ` Robert I. Eachus
2004-01-10 19:09                 ` Robert A Duff
2004-01-11 14:27                   ` Robert I. Eachus [this message]
2004-01-11 21:42                     ` Ze Administrator
2004-01-12  5:16                       ` Robert I. Eachus
2004-01-09  1:28         ` Adam Beneschan
2004-01-09  4:10           ` Ze Administrator
2004-01-09 11:27             ` Dmitry A. Kazakov
2004-01-09 23:09               ` Robert A Duff
2004-01-10 11:56                 ` Dmitry A. Kazakov
2004-01-10 17:08                   ` Robert I. Eachus
2004-01-10 18:40                   ` Robert A Duff
2004-01-09 23:08             ` Robert A Duff
2004-01-10  7:39               ` Robert I. Eachus
2004-01-08 20:36       ` tmoran
2004-01-08 21:06         ` Robert A Duff
2004-01-09  0:27       ` Randy Brukardt
2004-01-09  1:23       ` Adam Beneschan
2004-01-09  1:38         ` Robert A Duff
2004-01-09  6:16       ` Robert I. Eachus
2004-01-09 23:27         ` Randy Brukardt
2004-01-10 16:37           ` Robert I. Eachus
     [not found] ` <hmfvc1-f73.ln1@beastie.ix.netcom.com>
     [not found]   ` <l7v1d1-n33.ln1@beastie.ix.netcom.com>
2004-01-09 23:19     ` Robert A Duff
2004-01-09 23:21     ` Randy Brukardt
  -- strict thread matches above, loose matches on Subject: below --
2004-01-09  5:48 christoph.grein
2004-01-09  6:03 christoph.grein
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox