* Re: Language lawyer question: Equality on 'Access attributes @ 2004-01-09 5:48 christoph.grein 0 siblings, 0 replies; 40+ messages in thread From: christoph.grein @ 2004-01-09 5:48 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes
@ 2004-01-09 6:03 christoph.grein
0 siblings, 0 replies; 40+ messages in thread
From: christoph.grein @ 2004-01-09 6:03 UTC (permalink / raw)
To: comp.lang.ada, adam
> 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"...
^ permalink raw reply [flat|nested] 40+ messages in thread
* Language lawyer question: Equality on 'Access attributes @ 2004-01-08 2:05 Adam Beneschan 2004-01-08 7:47 ` Robert I. Eachus [not found] ` <hmfvc1-f73.ln1@beastie.ix.netcom.com> 0 siblings, 2 replies; 40+ messages in thread From: Adam Beneschan @ 2004-01-08 2:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-08 2:05 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 [not found] ` <hmfvc1-f73.ln1@beastie.ix.netcom.com> 1 sibling, 2 replies; 40+ messages in thread From: Robert I. Eachus @ 2004-01-08 7:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-08 7:47 ` Robert I. Eachus @ 2004-01-08 11:07 ` Dmitry A. Kazakov 2004-01-08 17:18 ` Adam Beneschan 1 sibling, 0 replies; 40+ messages in thread From: Dmitry A. Kazakov @ 2004-01-08 11:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 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 1 sibling, 1 reply; 40+ messages in thread From: Adam Beneschan @ 2004-01-08 17:18 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-08 17:18 ` Adam Beneschan @ 2004-01-08 18:04 ` Robert A Duff 2004-01-08 18:31 ` Ze Administrator ` (4 more replies) 0 siblings, 5 replies; 40+ messages in thread From: Robert A Duff @ 2004-01-08 18:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 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 1:28 ` Adam Beneschan 2004-01-08 20:36 ` tmoran ` (3 subsequent siblings) 4 siblings, 2 replies; 40+ messages in thread From: Ze Administrator @ 2004-01-08 18:31 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 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 4:06 ` Ze Administrator 2004-01-09 1:28 ` Adam Beneschan 1 sibling, 2 replies; 40+ messages in thread From: Robert A Duff @ 2004-01-08 21:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 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-09 4:06 ` Ze Administrator 1 sibling, 1 reply; 40+ messages in thread From: Ze Administrator @ 2004-01-09 4:02 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-09 4:02 ` Ze Administrator @ 2004-01-09 23:02 ` Robert A Duff 2004-01-10 2:56 ` Ze Administrator 0 siblings, 1 reply; 40+ messages in thread From: Robert A Duff @ 2004-01-09 23:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-09 23:02 ` Robert A Duff @ 2004-01-10 2:56 ` Ze Administrator 0 siblings, 0 replies; 40+ messages in thread From: Ze Administrator @ 2004-01-10 2:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-08 21:04 ` Robert A Duff 2004-01-09 4:02 ` Ze Administrator @ 2004-01-09 4:06 ` Ze Administrator 2004-01-09 23:05 ` Robert A Duff 1 sibling, 1 reply; 40+ messages in thread From: Ze Administrator @ 2004-01-09 4:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 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 7:19 ` Robert I. Eachus 0 siblings, 2 replies; 40+ messages in thread From: Robert A Duff @ 2004-01-09 23:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 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 1 sibling, 1 reply; 40+ messages in thread From: Ze Administrator @ 2004-01-10 3:03 UTC (permalink / raw) 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? :-) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-10 3:03 ` Ze Administrator @ 2004-01-10 13:47 ` Marin David Condic 0 siblings, 0 replies; 40+ messages in thread From: Marin David Condic @ 2004-01-10 13:47 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-09 23:05 ` Robert A Duff 2004-01-10 3:03 ` Ze Administrator @ 2004-01-10 7:19 ` Robert I. Eachus 2004-01-10 19:09 ` Robert A Duff 1 sibling, 1 reply; 40+ messages in thread From: Robert I. Eachus @ 2004-01-10 7:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-10 7:19 ` Robert I. Eachus @ 2004-01-10 19:09 ` Robert A Duff 2004-01-11 14:27 ` Robert I. Eachus 0 siblings, 1 reply; 40+ messages in thread From: Robert A Duff @ 2004-01-10 19:09 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-10 19:09 ` Robert A Duff @ 2004-01-11 14:27 ` Robert I. Eachus 2004-01-11 21:42 ` Ze Administrator 0 siblings, 1 reply; 40+ messages in thread From: Robert I. Eachus @ 2004-01-11 14:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-11 14:27 ` Robert I. Eachus @ 2004-01-11 21:42 ` Ze Administrator 2004-01-12 5:16 ` Robert I. Eachus 0 siblings, 1 reply; 40+ messages in thread From: Ze Administrator @ 2004-01-11 21:42 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-11 21:42 ` Ze Administrator @ 2004-01-12 5:16 ` Robert I. Eachus 0 siblings, 0 replies; 40+ messages in thread From: Robert I. Eachus @ 2004-01-12 5:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-08 18:31 ` Ze Administrator 2004-01-08 21:04 ` Robert A Duff @ 2004-01-09 1:28 ` Adam Beneschan 2004-01-09 4:10 ` Ze Administrator 1 sibling, 1 reply; 40+ messages in thread From: Adam Beneschan @ 2004-01-09 1:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 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:08 ` Robert A Duff 0 siblings, 2 replies; 40+ messages in thread From: Ze Administrator @ 2004-01-09 4:10 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 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-09 23:08 ` Robert A Duff 1 sibling, 1 reply; 40+ messages in thread From: Dmitry A. Kazakov @ 2004-01-09 11:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-09 11:27 ` Dmitry A. Kazakov @ 2004-01-09 23:09 ` Robert A Duff 2004-01-10 11:56 ` Dmitry A. Kazakov 0 siblings, 1 reply; 40+ messages in thread From: Robert A Duff @ 2004-01-09 23:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 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 0 siblings, 2 replies; 40+ messages in thread From: Dmitry A. Kazakov @ 2004-01-10 11:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-10 11:56 ` Dmitry A. Kazakov @ 2004-01-10 17:08 ` Robert I. Eachus 2004-01-10 18:40 ` Robert A Duff 1 sibling, 0 replies; 40+ messages in thread From: Robert I. Eachus @ 2004-01-10 17:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-10 11:56 ` Dmitry A. Kazakov 2004-01-10 17:08 ` Robert I. Eachus @ 2004-01-10 18:40 ` Robert A Duff 1 sibling, 0 replies; 40+ messages in thread From: Robert A Duff @ 2004-01-10 18:40 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-09 4:10 ` Ze Administrator 2004-01-09 11:27 ` Dmitry A. Kazakov @ 2004-01-09 23:08 ` Robert A Duff 2004-01-10 7:39 ` Robert I. Eachus 1 sibling, 1 reply; 40+ messages in thread From: Robert A Duff @ 2004-01-09 23:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-09 23:08 ` Robert A Duff @ 2004-01-10 7:39 ` Robert I. Eachus 0 siblings, 0 replies; 40+ messages in thread From: Robert I. Eachus @ 2004-01-10 7:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-08 18:04 ` Robert A Duff 2004-01-08 18:31 ` Ze Administrator @ 2004-01-08 20:36 ` tmoran 2004-01-08 21:06 ` Robert A Duff 2004-01-09 0:27 ` Randy Brukardt ` (2 subsequent siblings) 4 siblings, 1 reply; 40+ messages in thread From: tmoran @ 2004-01-08 20:36 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-08 20:36 ` tmoran @ 2004-01-08 21:06 ` Robert A Duff 0 siblings, 0 replies; 40+ messages in thread From: Robert A Duff @ 2004-01-08 21:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-08 18:04 ` Robert A Duff 2004-01-08 18:31 ` Ze Administrator 2004-01-08 20:36 ` tmoran @ 2004-01-09 0:27 ` Randy Brukardt 2004-01-09 1:23 ` Adam Beneschan 2004-01-09 6:16 ` Robert I. Eachus 4 siblings, 0 replies; 40+ messages in thread From: Randy Brukardt @ 2004-01-09 0:27 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-08 18:04 ` Robert A Duff ` (2 preceding siblings ...) 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 4 siblings, 1 reply; 40+ messages in thread From: Adam Beneschan @ 2004-01-09 1:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-09 1:23 ` Adam Beneschan @ 2004-01-09 1:38 ` Robert A Duff 0 siblings, 0 replies; 40+ messages in thread From: Robert A Duff @ 2004-01-09 1:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-08 18:04 ` Robert A Duff ` (3 preceding siblings ...) 2004-01-09 1:23 ` Adam Beneschan @ 2004-01-09 6:16 ` Robert I. Eachus 2004-01-09 23:27 ` Randy Brukardt 4 siblings, 1 reply; 40+ messages in thread From: Robert I. Eachus @ 2004-01-09 6:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-09 6:16 ` Robert I. Eachus @ 2004-01-09 23:27 ` Randy Brukardt 2004-01-10 16:37 ` Robert I. Eachus 0 siblings, 1 reply; 40+ messages in thread From: Randy Brukardt @ 2004-01-09 23:27 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes 2004-01-09 23:27 ` Randy Brukardt @ 2004-01-10 16:37 ` Robert I. Eachus 0 siblings, 0 replies; 40+ messages in thread From: Robert I. Eachus @ 2004-01-10 16:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <hmfvc1-f73.ln1@beastie.ix.netcom.com>]
[parent not found: <l7v1d1-n33.ln1@beastie.ix.netcom.com>]
* Re: Language lawyer question: Equality on 'Access attributes [not found] ` <l7v1d1-n33.ln1@beastie.ix.netcom.com> @ 2004-01-09 23:19 ` Robert A Duff 2004-01-09 23:21 ` Randy Brukardt 1 sibling, 0 replies; 40+ messages in thread From: Robert A Duff @ 2004-01-09 23:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Language lawyer question: Equality on 'Access attributes [not found] ` <l7v1d1-n33.ln1@beastie.ix.netcom.com> 2004-01-09 23:19 ` Robert A Duff @ 2004-01-09 23:21 ` Randy Brukardt 1 sibling, 0 replies; 40+ messages in thread From: Randy Brukardt @ 2004-01-09 23:21 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2004-01-12 5:16 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-01-09 5:48 Language lawyer question: Equality on 'Access attributes christoph.grein -- strict thread matches above, loose matches on Subject: below -- 2004-01-09 6:03 christoph.grein 2004-01-08 2:05 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox