CVS difference for ais/ai-00241.txt

Differences between 1.9 and version 1.10
Log of other versions for file ais/ai-00241.txt

--- ais/ai-00241.txt	2002/06/11 05:15:48	1.9
+++ ais/ai-00241.txt	2005/10/31 05:18:14	1.10
@@ -165,12 +165,261 @@
 that is a mistake, though others might remember otherwise.
 >>
 
-Well I would be happy to allow this identity, though this would be a
-change
-(in GNAT we could add a child, but not change clear RM semantics),
-but
-if one is in the amendment business, perhaps allowing the above
-identity
+Well I would be happy to allow this identity, though this would be a change
+(in GNAT we could add a child, but not change clear RM semantics), but
+if one is in the amendment business, perhaps allowing the above identity
 is the cleanest approach.
 
 ****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, May 1, 2005  7:00 AM
+
+This is rated as easy, but in fact it's one of the nastiest AI's
+I have run across so far. Why? Because it requires clearly
+incompatible behavior between Ada 95 and Ada 2005 at run time,
+and we have not encountered this requirement yet, which will
+require a completely new mechanism in the compiler.
+
+Are we sure that was the intention here.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Sunday, May 1, 2005  9:09 AM
+
+True, but changing an exception to some reasonable behavior is not as
+bad as changing behavior in other ways.  I think we did that in
+various ways in the 83-to-95 change.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, May 1, 2005  6:49 PM
+
+Yes, I agree, and that is why I think we should allow this new
+preferable behavior to be implemented in Ada 95 compilers.
+
+Presumably however, the worry is that existing code tests for
+a null exception precisely by catching the expected exception,
+so the change is indeed potentially incompatible.
+
+In fact once I think in those terms, it seems that this AI is
+really proposing a *quite* incompatible change.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, May 1, 2005  6:57 PM
+
+> Are we sure that was the intention here.
+
+Yes.
+
+Two points:
+
+This AI is a binding interpretation; it applies to Ada 95 as well as Ada
+2006. So there is no inconsistency in that sense (even though it is
+documented in the AARM as one). An implementation of either language that
+raises an exception in this case is wrong. Indeed, I've long since removed
+the part of the ACATS test that required an exception to be raised (whether
+it is ever replaced by a test requiring the new behavior remains to be
+seen). Of course, an implementor can always do whatever they want in a
+non-standard mode (including supporting Ada 95 without the most recent set
+of BIs), but that's not relevant to how the standard should work.
+
+Second, there are 12 clauses in the draft AARM that contain "Inconsistencies
+with Ada 95" items. These of course are run-time differences from Ada 95.
+Most of them are obscure cases that ought not come up in practice, but
+they're there. There also were several cases where I didn't document a
+difference because the construct was erroneous or unspecified in Ada 95; but
+code that depends on that anyway might also need to change its effect. (And
+it wouldn't surprise me if I missed a couple of inconsistencies when writing
+the standard.) So you'll probably need some mechanism for runtime
+differences if you intend to support strict Ada 95 compatibility.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, May 1, 2005  7:05 PM
+
+> Yes.
+
+I am completely confused, you say Yes above but ...
+
+> Two points:
+>
+> This AI is a binding interpretation; it applies to Ada 95 as well as Ada
+> 2006. So there is no inconsistency in that sense (even though it is
+> documented in the AARM as one). An implementation of either language that
+> raises an exception in this case is wrong. Indeed, I've long since removed
+> the part of the ACATS test that required an exception to be raised (whether
+> it is ever replaced by a test requiring the new behavior remains to be
+> seen). Of course, an implementor can always do whatever they want in a
+> non-standard mode (including supporting Ada 95 without the most recent set
+> of BIs), but that's not relevant to how the standard should work.
+
+This clearly says no ... incompatible behavior is not required ...
+
+> Second, there are 12 clauses in the draft AARM that contain "Inconsistencies
+> with Ada 95" items. These of course are run-time differences from Ada 95.
+> Most of them are obscure cases that ought not come up in practice, but
+> they're there. There also were several cases where I didn't document a
+> difference because the construct was erroneous or unspecified in Ada 95; but
+> code that depends on that anyway might also need to change its effect. (And
+> it wouldn't surprise me if I missed a couple of inconsistencies when writing
+> the standard.) So you'll probably need some mechanism for runtime
+> differences if you intend to support strict Ada 95 compatibility.
+
+What does strict Ada 95 compatibility mean, surely a strictly Ada 95
+compatible compiler must implement any binding interpreations issued
+by the ARG.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, May 1, 2005  7:33 PM
+
+Robert Dewar wrote:
+
+...
+> I am completely confused, you say Yes above but ...
+
+I meant that the behavior is different from that originally defined for Ada
+95, and that is intentional.
+
+...
+> > So you'll probably need some mechanism for runtime
+> > differences if you intend to support strict Ada 95 compatibility.
+>
+> What does strict Ada 95 compatibility mean, surely a strictly Ada 95
+> compatible compiler must implement any binding interpreations issued
+> by the ARG.
+
+I don't think anywhere near all of them are caused by BIs. Some of them have
+to do with the character set stuff (the behavior of
+Wide_Character'Wide_Image for non-graphic characters, for example), and
+those clearly aren't BIs. Indeed, I tried not to document differences caused
+by BIs (AI-241 being an exception).
+
+So I still think that you'll need a way to select Ada 95 behavior at runtime
+if you want strict compatibility. (I'd have to go back and look at all of
+them again to see how important that is.)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, May 1, 2005  9:14 PM
+
+> I meant that the behavior is different from that originally defined for Ada
+> 95, and that is intentional.
+
+Well there are *many* cases of binding interpretations for sure,
+but that's not my concern at all.
+
+> I don't think anywhere near all of them are caused by BIs. Some of them have
+> to do with the character set stuff (the behavior of
+> Wide_Character'Wide_Image for non-graphic characters, for example), and
+> those clearly aren't BIs. Indeed, I tried not to document differences caused
+> by BIs (AI-241 being an exception).
+
+But that's strictly compile time
+
+> So I still think that you'll need a way to select Ada 95 behavior at runtime
+> if you want strict compatibility. (I'd have to go back and look at all of
+> them again to see how important that is.)
+
+Well apparently AI-241 is not an example of this. If you think there
+is one, I would be interested.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, May 1, 2005  11:32 PM
+
+...
+> > I don't think anywhere near all of them are caused by BIs. Some of them
+have
+> > to do with the character set stuff (the behavior of
+> > Wide_Character'Wide_Image for non-graphic characters, for example), and
+> > those clearly aren't BIs. Indeed, I tried not to document differences
+caused
+> > by BIs (AI-241 being an exception).
+>
+> But that's strictly compile time
+
+Huh? Since when is the result of 'Image (and the strings accepted by 'Value)
+"strictly compile-time".
+
+AI-285 (as modified by AI-395) defines the result of 'Image differently for
+non-graphic characters than Ada 95 did. It also gets rid of the funny "FFFE"
+image.
+
+In particular, Wide_Character'Image(Wide_Character'Pos(16#FFFE#)) = "FFFE"
+in Ada 95, and "HEX_0000FFFE" in Ada 2006. And of course 'Value is the
+reverse of this.
+
+(This last change wasn't strictly necessary, but once compatibility had been
+dropped for other non-graphic characters, there was no benefit to keeping it
+for this character, which isn't supposed to ever be used anyway.)
+
+...
+> Well apparently AI-241 is not an example of this. If you think there
+> is one, I would be interested.
+
+See above. There are other examples in the draft AARM, for instance, an
+object can be unconstrained in the heap in certain circumstances, which
+would eliminate constraint_errors that would occur in Ada 95 (AI-363). Look
+for "Inconsistencies with Ada 95" in the AARM. These are considered the
+worst issues, so everything that conceivably could be there is documented
+there. At least if I thought of it when adding those AIs.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, May 2, 2005  6:36 AM
+
+...
+> Huh? Since when is the result of 'Image (and the strings accepted by 'Value)
+> "strictly compile-time".
+>
+> AI-285 (as modified by AI-395) defines the result of 'Image differently for
+> non-graphic characters than Ada 95 did. It also gets rid of the funny "FFFE"
+> image.
+>
+> In particular, Wide_Character'Image(Wide_Character'Pos(16#FFFE#)) = "FFFE"
+> in Ada 95, and "HEX_0000FFFE" in Ada 2006. And of course 'Value is the
+> reverse of this.
+
+Well true, but this is too marginal to worry about, no program
+is counting on this kind of thing (obviously the ARG feels the
+same way, since it feels free to introduce serious casual
+incompatibilities in this area :-) Next you will be worrying
+about the idiotic Width attribute giving different results
+(idiotic, because the business of dealing at run time with
+dynamic subtypes is absurd).
+
+I would actually specifically allow compilers to adopt the new
+behavior for image in Ada 95, just as we allowed Ada 83 compilers
+to move to 8-bit characters before Ada 95 appeared.
+
+> See above. There are other examples in the draft AARM, for instance, an
+> object can be unconstrained in the heap in certain circumstances, which
+> would eliminate constraint_errors that would occur in Ada 95 (AI-363). Look
+> for "Inconsistencies with Ada 95" in the AARM. These are considered the
+> worst issues, so everything that conceivably could be there is documented
+> there. At least if I thought of it when adding those AIs.
+
+The unconstrained objects on the heap business (what an awful junk
+change to the language -- first time that making a type private
+completely changes its behavior -- and a serious incompatibility
+with Ada 95) is compile time only, since you know at compile time
+what types are affected, I don't see any point at which there would
+be an issue here requiring a run-time check, or different run times.
+
+We really don't want run-time penalties for compilers that try to
+accomodate Ada 95 and Ada 2005 at the same time, since this is the
+natural way to encourage transition.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent