CVS difference for ais/ai-00230.txt
--- ais/ai-00230.txt 2005/12/15 02:43:49 1.28
+++ ais/ai-00230.txt 2006/01/10 22:17:39 1.29
@@ -2777,3 +2777,458 @@
*************************************************************
+From: Robert A. Duff
+Sent: Friday, January 6, 2006 7:17 PM
+
+Wording question related to user-defined "=" operators:
+
+RM-4.5.2 says:
+
+6 The equality operators are predefined for every specific type T that is
+not limited, and not an anonymous access type, with the following
+specifications:
+
+So equality operators are predefined for composite types containing anonymous
+access types:
+
+ type T is
+ record
+ X: access Integer;
+ end record;
+ -- function "="(Left, Right: T) return Boolean is predefined.
+
+But (for composite types):
+
+24 Otherwise, the result is defined in terms of the primitive equals
+ operator for any matching tagged components, and the predefined equals
+ for any matching untagged components.
+
+But the "predefined equals" for X above does not exist.
+
+Furthermore, the notion of "THE primitive equals operator" is questionable
+wording:
+
+ package P is
+ type T is tagged...;
+ function "="(X: T; Y: Integer) return Integer;
+
+"=" is primitive of T, and it's an "equals operator", but it's not intended to
+be THE primitive equals operator of T.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Saturday, January 7, 2006 9:13 AM
+
+> 24 Otherwise, the result is defined in terms of the primitive equals
+> operator for any matching tagged components, and the predefined equals
+> for any matching untagged components.
+>
+> But the "predefined equals" for X above does not exist.
+
+I think that clearly has to refer to the predefined equals
+operator in Standard applicable to all anonymous access
+types. What else could it mean?
+
+It is interesting to me that we debated whether we should have
+this predefined equality operator in Standard somewhat independently
+of whether we should have anonymous access type components
+and discriminants of non-limited composite types. But as you
+point out, there is a clear need for some kind of predefined
+equality operator for anonymous access types as soon as we
+allow them as components of non-limited types.
+
+>
+> Furthermore, the notion of "THE primitive equals operator" is questionable
+> wording:
+>
+> package P is
+> type T is tagged...;
+> function "="(X: T; Y: Integer) return Integer;
+>
+> "=" is primitive of T, and it's an "equals operator", but it's not intended to
+> be THE primitive equals operator of T.
+
+True, though this hasn't changed since Ada 95, and clearly has
+been interpreted by every implementation (and hopefully every user)
+to mean the primitive equals operator where both operands
+are of the same type.
+
+Neither of these seems too bad on the scale of wording clarity.
+Did you encounter a problem or question that highlighted
+the admitted possible ambiguity?
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, January 7, 2006 6:46 PM
+
+...
+> RM-4.5.2 says:
+...
+> But (for composite types):
+>
+> 24 Otherwise, the result is defined in terms of the primitive equals
+> operator for any matching tagged components, and the predefined equals
+> for any matching untagged components.
+>
+> But the "predefined equals" for X above does not exist.
+
+It probably would be best to fix this wording to say the "predefined equals
+for universal_access for any matching anonymous access components, and the
+predefined equals for any other matching untagged components."
+
+But, as Tucker points out, this seems like a fine point.
+
+> Furthermore, the notion of "THE primitive equals operator" is questionable
+> wording:
+...
+
+Sure. But this is Ada 95 wording; nothing has changed, and you probably
+wrote this wording yourself :-), so I don't think it is worth changing.
+
+And in any case, you have to suggest replacement wording, not just gripe.
+:-) :-)
+"the primitive equals operator with both parameters of the type and
+returning Boolean" seems like too much.
+
+Perhaps both issues should be addressed by a "To Be Honest" note???
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Sunday, January 8, 2006 9:08 AM
+
+> ...
+> Perhaps both issues should be addressed by a "To Be Honest" note???
+
+That would be my inclination, unless Bob sees a more
+serious problem underlying the current words.
+I don't at the moment see any possibility for actual
+confusion.
+
+*************************************************************
+
+From: Robert A. Duff
+Sent: Sunday, January 8, 2006 12:07 PM
+
+I was momentarily confused about the anon access case.
+The other case is pure nitpicking.
+
+Anyway, I agree with Randy and Tuck here -- To Be Honest is sufficient.
+
+**************************************************************
+
+From: Robert I. Eachus
+Sent: Saturday, January 7, 2006 9:44 PM
+
+>24 Otherwise, the result is defined in terms of the primitive equals
+> operator for any matching tagged components, and the predefined equals for
+> any matching untagged components.
+
+Technically I guess that removing the two 'any's would clarify this. You
+could even go so far as to say "the primitive equals for pairs of
+matching tagged components, and the predefined equals for pairs of
+matching untagged components..." But that seems excessive to me.
+
+As for the issue of equality of anonymous access types, I think a note
+would be appropriate. Especially if the note made it clear what happens
+if one of the access values resulted from a call to Unchecked_Access and
+is no longer valid. (Thinking about it, a note for the Unchecked_Access
+case really belongs in 4.5.2.) Or maybe it shouldn't be a note? My
+inclination is to allow code to seg fault in this case, but there is a
+lot to be said for requiring that 4.5.2(33) Note 13 hold:
+
+13 No exception is ever raised by a membership test, by a predefined
+ordering operator, or by a predefined equality
+operator for an elementary type, but an exception can be raised by the
+evaluation of the operands. A predefined equality
+operator for a composite type can only raise an exception if the type
+has a tagged part whose primitive equals operator
+propagates an exception.
+
+It is tempting to leave the comparison to a no longer valid annonymous
+access value as an erroneous execution case. However, I suspect that
+all realistic compilers would not have any work to do if this is made a
+bounded error, returning True or False. (The corner case would be when
+the stack grows, then shrinks, and the now unused pages for the stack
+are given back to the OS. Does anyone do that?) This just seems like
+it should be less dangerous than the case where a programmer has called
+Unchecked_Deallocation on an object of a (named) access type. That does
+result in a bounded error, at least for realistic cases.
+
+**************************************************************
+
+From: Pascal Leroy
+Sent: Monday, January 9, 2006 2:14 AM
+
+> It is tempting to leave the comparison to a no longer valid
+> annonymous
+> access value as an erroneous execution case.
+
+This has been discussed many times in the past, and there doesn't seem to
+be any good reason for erroneousness here.
+
+An invalid access value is just a bit pattern. You want to test it for
+equality, fine, compare that bit pattern using one or several integer
+comparison instructions. I can't think of a machine where that would be
+problematic. Also, I can't think of a reason why you would want to
+dereference the access value or otherwise check that it corresponds to a
+valid address in order to implement equality. The bottom line is, the
+natural implementation is that you get either True or False, but no
+erroneousness.
+
+Of course, if you *dereference* such an access value (e.g., by using .all
+in the source) then all bets are off.
+
+None of that is specific to anonymous access types, btw.
+
+**************************************************************
+
+From: Robert Dewar
+Sent: Monday, January 9, 2006 5:38 AM
+
+> An invalid access value is just a bit pattern. You want to test it for
+>
+>equality, fine, compare that bit pattern using one or several integer
+>comparison instructions. I can't think of a machine where that would be
+>problematic. Also, I can't think of a reason why you would want to
+>dereference the access value or otherwise check that it corresponds to a
+>valid address in order to implement equality. The bottom line is, the
+>natural implementation is that you get either True or False, but no
+>erroneousness.
+
+I agree. In fact I would generalize and say that ALL comparisons of
+discrete types and access values
+(not fpt), will always generate True or False under all circumstances.
+
+**************************************************************
+
+From: Robert I. Eachus
+Sent: Monday, January 9, 2006 2:49 PM
+
+...
+>None of that is specific to anonymous access types, btw.
+
+I totally agree that there is no reason to allow an exception or worse
+in this case. I just can't find in the RM where it says that. Or
+rather, RM 4.5.2(33), which is a note, goes out of its way to be
+ambiguous in this case: (Quoting from draft 15.)
+
+13 No exception is ever raised by a membership test, by a predefined
+ordering operator, or by a predefined equality
+operator for an elementary type, but an exception can be raised by the
+evaluation of the operands. A predefined equality
+operator for a composite type can only raise an exception if the type
+has a tagged part whose primitive equals operator
+propagates an exception.
+
+Yes, it is common sense that equality for annonymous access types does
+not need to dereference the values to compare them, but we are now
+navigating in murky water. There is still hardware around where loading
+an invalid bit-pattern into an address register can cause a problem.
+(For example, the Motorola 68000, but not the 68020 or later, would not
+allow an odd byte address in certain registers. A more modern example
+is that some 64-bit hardware requires that some of the upper bits of a
+valid address be zero.) That should not be an issue here. We know that
+at one point the address was valid, and even if the data is no longer
+valid, the bit pattern should still be safe.
+
+That is what I was referring to above. Should be easy enough to fix.
+Just add a statement to 4.5.2 saying that equality for access types does
+not read the designated values of its parameters. But that starts to
+open the can of worms I suggested we leave closed. RM 4.5.2(13) is
+intended to allow access-to-subprogram values to be handles, or to in
+some other way encode the context of a particular suprogram instance.
+Should equality for access-to-subprogram values be allowed to
+dereference the handle, but not the designated subprogram?
+
+As I said, I think that this corner of the language is best left
+undefined. To me using the predefined testing for equality of an object
+containing pointers (whatever we call them) is of dubious value anyway.
+Defining what happens when one or more of those pointers is invalid is
+even less likely to ever matter to anyone. Not testing access values
+for equality, but testing structures containing access values for equality.
+
+In most such cases the programmer defining the type will probably want
+to define what equality means, or even if it is valid. Which of course
+is how we got here. The original issue under discussion was a paragraph
+defining equality for containers that do, in fact, have a generic formal
+equality operator for elements. Further our goal was not to specify the
+equality operation more strictly, but to rewrite the paragraph to insure
+that (potentially) unnecessary calls to the generic formal "=" are
+permitted but not required.
+
+**************************************************************
+
+From: Robert Dewar
+Sent: Monday, January 9, 2006 6:14 PM
+
+> 13 No exception is ever raised by a membership test, by a predefined
+> ordering operator, or by a predefined equality
+> operator for an elementary type, but an exception can be raised by the
+> evaluation of the operands. A predefined equality
+> operator for a composite type can only raise an exception if the type
+> has a tagged part whose primitive equals operator
+> propagates an exception.
+
+AArgh! aren't floating-point types elementary? It is obvious that a fpt
+equality test can raise an exception if the arguments are invalid
+representations and happen to be signalling NaN's
+
+**************************************************************
+
+From: Randy Brukardt
+Sent: Monday, January 9, 2006 11:40 PM
+
+Well, this is a note, so it has no normative impact. And it dates back to
+Ada 95. OTOH, there are a number of counter-examples here, and we generally
+don't want notes that are wrong. I think we could make an argument for
+deleting it, but I have to wonder if it is sufficiently wrong for that...
+
+**************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, January 10, 2006 3:25 AM
+
+I would assume that an sNaN is an invalid representation, and that using
+it is a bounded error that can raise C_E or P_E (see 13.9.1(9)). So this
+appears to be covered by normative wording. The note might be slightly
+misleading, but we don't normally clutter notes with junk that says
+"except in the case of bounded errors, erroneous execution, plague or
+pestilence".
+
+The same applies if an implementation chooses to implement some
+fixed-point types using a float representation, which is legitimate
+assuming that it can provide the appropriate high-level semantics. sNaN
+is invalid and an exception is raised.
+
+**************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, January 10, 2006 5:56 AM
+
+>Well, this is a note, so it has no normative impact. And it dates back to
+>Ada 95. OTOH, there are a number of counter-examples here, and we generally
+>don't want notes that are wrong. I think we could make an argument for
+>deleting it, but I have to wonder if it is sufficiently wrong for that...
+
+Yes, it is sufficiently wrong, because it might induce people to think that fpt
+comparisons are safe. And it might even make implementors think they have to
+futz around catching NaN exceptions.
+
+**************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, January 10, 2006 5:59 AM
+
+>I would assume that an sNaN is an invalid representation, and that using
+>it is a bounded error that can raise C_E or P_E (see 13.9.1(9)). So this
+>appears to be covered by normative wording. The note might be slightly
+>misleading, but we don't normally clutter notes with junk that says
+>"except in the case of bounded errors, erroneous execution, plague or
+>pestilence".
+
+But this note is complete junk for the normal case, of course equality
+works in these cases.
+
+>The same applies if an implementation chooses to implement some
+>fixed-point types using a float representation, which is legitimate
+>assuming that it can provide the appropriate high-level semantics. sNaN
+>is invalid and an exception is raised.
+
+So just junk the note. It is actively unhelpful
+
+**************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, January 10, 2006 6:01 AM
+
+>The same applies if an implementation chooses to implement some
+>fixed-point types using a float representation, which is legitimate
+>assuming that it can provide the appropriate high-level semantics. sNaN
+>is invalid and an exception is raised.
+
+Note that in my previous message I said discrete or access types, and that's
+because the above situation is perfectly reasonable and familiar. I do think
+there is some advantage in stopping implementations from doing peculiar things
+in the discrete/access type cases.
+
+**************************************************************
+
+From: Robert A. Duff
+Sent: Tuesday, January 10, 2006 8:29 AM
+
+> Well, this is a note, so it has no normative impact. And it dates back to
+> Ada 95. OTOH, there are a number of counter-examples here, and we generally
+> don't want notes that are wrong. I think we could make an argument for
+> deleting it, but I have to wonder if it is sufficiently wrong for that...
+
+There was a similar note in Ada 83, and the above wording was an attempt to
+salvage the note by making it correct. We probably should have just deleted it
+in Ada 95. It doesn't say anything terribly interesting for Ada 83, and even
+less so for Ada 95, because of the new rules about invalid values.
+
+In "X = Y", if X is a signalling NaN, the evaluation of X is what raises the
+exception. The "=" does not raise an exception in that case, but so what?
+
+I say, delete the note. It's unhelpful, and if you're not a language lawyer,
+it could be misleading.
+
+**************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, January 10, 2006 3:59 PM
+
+> In "X = Y", if X is a signalling NaN, the evaluation of X is what
+> raises the exception. The "=" does not raise an exception in that case,
+> but so what?
+
+Not always .. on some machines it is the equality operation which would
+trap. In any case the distinction is unhelpful!
+
+>I say, delete the note. It's unhelpful, and if you're not a language lawyer,
+>it could be misleading.
+
+I agree.
+
+**************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 10, 2006 4:02 PM
+
+> Note that in my previous message I said discrete or access types, and
+> that's because the above situation is perfectly reasonable and familiar.
+> I do think there is some advantage in stopping implementations from doing
+> peculiar things in the discrete/access type cases.
+
+But, normatively, the situation is the same. It would be easy to imagine an
+implementation that raised Program_Error if it read an invalid holey
+enumeration value, for instance. (Indeed, Janus/Ada would do just that, if the
+optimizer is off; canonically, all holey enumeration values are loaded into
+registers as position numbers (so as to be able to use them for indexing and
+looping). The optimizer removes unneeded lookups, but if it is off, the
+operation would occur and raise an exception.)
+
+If we *really* wanted to say something about discrete and/or access type
+comparisons, I think we'd need Implementation Advice. (I cannot see how we
+could make this a requirement, given that it would be a "not withstanding"
+rule. And there are a lot of cases identified where there might be a problem.)
+Which is a lot bigger deal than removing a confusing note, and probably too
+late for the Amendment.
+
+**************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 10, 2006 4:15 PM
+
+I also should comment that such an IA would be rather contrary to the decision
+for validity elsewhere (as discussed in AI-426). We essentially decided that an
+implementation is never required to store an invalid value; it is *always*
+allowed to raise an exception instead (of course, it can store invalid values
+if it wants to). It would seem very odd to say something different here; this
+case doesn't seem anywhere near as important as the Unchecked_Conversion one
+that we were discussing in AI-426.
+
+*************************************************************
+
Questions? Ask the ACAA Technical Agent