From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d402e2c741db0d0 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-09 23:19:20 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!newsfeed.mathworks.com!wn11feed!worldnet.att.net!216.166.71.14!border3.nntp.aus1.giganews.com!intern1.nntp.aus1.giganews.com!nntp.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 10 Jan 2004 01:19:17 -0600 Date: Sat, 10 Jan 2004 02:19:17 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Language lawyer question: Equality on 'Access attributes References: <4LKdnRRNyv6AlmCiRVn-ig@comcast.com> <6bSdnYBKy_diPGCi4p2dnA@gbronline.com> <5a6dnSHERdpJtWOi4p2dnA@gbronline.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.34.214.193 X-Trace: sv3-UsXC3VEDIsWVogYFbRKJ2yUx6dXPTx4dWK9IwOWJGwaI+Bct/zZ7qltppvle1JGJtMIzCWOl+1+OH7U!wDsODwrTjYLv1vKIeJgbfd2jn3WU/LA1ZodfIP2fbr0vNsOJA5ec2uZlmBRz1A== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:4296 Date: 2004-01-10T02:19:17-05:00 List-Id: 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