CVS difference for ais/ai-00439.txt

--- ais/ai-00439.txt	2005/12/15 02:44:21	1.4
+++ ais/ai-00439.txt	2006/01/10 22:17:52	1.5
@@ -543,3 +543,368 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Friday, December  9, 2005  8:15 AM
+
+You may be sensing a theme in my responses to these questions
+about incorporating Ada 2005 features into Ada 95.
+I don't see the point, especially when it is something
+that affects run-time semantics, which conceivably might
+change even without a recompile, only a re-link, and
+in any case is not necessarily going to be flagged by
+the compiler.
+
+The vendors are much less driven by ARG and ACAA decisions
+these days.  Users are similarly less aware of our decisions,
+given that they are not worrying much about ACATS validation.
+If we decide to change the semantics of something in Ada 95, it will
+ripple unevenly and slowly, if at all, through the various
+compilers out there.  And I just don't see the upside.
+
+It is easy enough for a compiler to have a "-2005" flag
+or configuration pragma.  If the user doesn't specify that,
+what value is it to them that something silently changes?
+They can't really take advantage of the new capability
+since not all Ada 95 compilers are certain to implement
+it.  Perhaps it simplifies the Ada 2005 implementation job
+for some vendors, but it sounds like the AdaCore folks have
+already decided to bite the bullet and support both semantics.
+
+I am all for adding Ada 2005 features to compilers as soon
+as possible.  I just haven't seen any case where the value to
+the user is so compelling that we need to encourage it to
+be silently slipped into (some but not all) "Ada 95"
+compilers, or into multi-version compilers running
+in "Ada 95" mode, and thereby make code *less* portable
+across Ada 95 compilers.
+
+As I have said several times, I am all for defining
+some subsets of Ada 2005 that multiple
+vendors can agree on, and define appropriate pragmas to
+select those.  One obvious one is the Ada 95 feature set but with
+Ada 2005 semantics, when there is a difference.
+I also see no harm in some small vendors dropping sales
+for Ada 95, and only selling Ada 2005-subset compilers.
+That is their business decision.  But if the users
+think the compiler is an Ada 95 compiler or are running
+in the Ada 95 "mode," I see no justification for them to
+see some random mixture of Ada 95 and Ada 2005 semantics.
+
+I can pretty much guarantee that every question like this
+that is asked will get the same answer from me, unless it is something
+that we decided to make a Binding Interpretation in the first
+place.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, December  9, 2005  8:39 AM
+
+> It is easy enough for a compiler to have a "-2005" flag
+> or configuration pragma.  If the user doesn't specify that,
+> what value is it to them that something silently changes?
+> They can't really take advantage of the new capability
+> since not all Ada 95 compilers are certain to implement
+> it.  Perhaps it simplifies the Ada 2005 implementation job
+> for some vendors, but it sounds like the AdaCore folks have
+> already decided to bite the bullet and support both semantics.
+
+Yes, but it is ugly and messy
+>
+> I am all for adding Ada 2005 features to compilers as soon
+> as possible.  I just haven't seen any case where the value to
+> the user is so compelling that we need to encourage it to
+> be silently slipped into (some but not all) "Ada 95"
+> compilers, or into multi-version compilers running
+> in "Ada 95" mode, and thereby make code *less* portable
+> across Ada 95 compilers.
+
+I am not talking about new features, I am talking about
+cases where the "new feature" is an upwards incompatible
+change.
+
+To me such changes are either
+
+a) significant semantically, in which case they are
+probably gratuitous, unless they are really important,
+which for sure is not true of Wide_Wide stuff in
+Ada.Exceptions, or null passed to Raise_Exception.
+
+or
+
+b) insignificant semantically, but a nice cleanup,
+in which case, backporting them to Ada 95 is harmless.
+
+To me Tuck is falling between these two. If case a holds
+then the proper thing to do is to remove these gratuitous
+non-upwards compatibilities. We don't want to have to
+tell customers that we have upwards incompatibilities
+that are significant when they are not significant.
+
+Or if case b holds, then why on earth junk up implementations
+and documentation just to maintain rubbish differences between
+Ada 95 and Ada 2005 mode.
+
+Portability is just plain irrelevant if case b holds. And
+if case a holds, then portability considerations dictate
+removing these junk incompatibilities.
+
+For me, these two cases, and especially the Raise_Exception
+case are solidly in the b) category.
+
+> I can pretty much guarantee that every question like this
+> that is asked will get the same answer from me, unless it is something
+> that we decided to make a Binding Interpretation in the first
+> place.
+
+I think that's inconsistent with the decision to handle these
+on a case by case basis.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, December  9, 2005  8:41 AM
+
+> The vendors are much less driven by ARG and ACAA decisions
+> these days.  Users are similarly less aware of our decisions,
+> given that they are not worrying much about ACATS validation.
+> If we decide to change the semantics of something in Ada 95, it will
+> ripple unevenly and slowly, if at all, through the various
+> compilers out there.  And I just don't see the upside.
+
+We don't really care much about ARG decisions if they are
+clearly wrong, though we would prefer to be compatible.
+We do care about conformance, and we do care about ACATS tests.
+
+SO for example, an ACATS test that passes null to Raise_Exception
+is in my opinion mischievous and useless, and should be
+expunged (I don't know if there is such a test now, or in the
+future, Randy?)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, December  9, 2005  8:57 AM
+
+> Or if case b holds, then why on earth junk up implementations
+> and documentation just to maintain rubbish differences between
+> Ada 95 and Ada 2005 mode.
+>
+> Portability is just plain irrelevant if case b holds. And
+> if case a holds, then portability considerations dictate
+> removing these junk incompatibilities.
+
+A standard is all about portability between *different*
+implementations of the *same* standard, not between the
+same implementor's implementation of two different standards.
+Unless we can get all Ada 95 compilers to rapidly adopt changes in
+semantics (especiallly run-time semantics), then
+we are only weakening the Ada 95 standard and hurting
+portability by allowing some implementors to adopt bits
+of Ada 2005 when and if it is convenient.
+
+> ...
+>> I can pretty much guarantee that every question like this
+>> that is asked will get the same answer from me, unless it is something
+>> that we decided to make a Binding Interpretation in the first
+>> place.
+>
+>
+> I think that's inconsistent with the decision to handle these
+> on a case by case basis.
+
+The one case I remember discussing in the ARG meeting was allowing
+"not null" to be added to "Ada 95" access parameters and
+access discriminants with *no* semantic effect.  I was in
+favor of this.  The ARG, based on a persuasive argument from
+Pascal about portability, decided against this.  So I guess
+I need a case that doesn't fall victim to Pascal's argument,
+and at least for me, something involving a subtle change in
+run-time semantics will have a much steeper hill to climb than
+something that is "harmless" and compile-time related (though
+it is hard for me to imagine something more benign than "not null").
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, December  9, 2005  9:02 AM
+
+I would also like to object to the subject here.
+
+This is NOT a matter of cherry picking Ada 95 features
+at all.
+
+It is focused ENTIRELY on non-upwards compatible changes.
+
+For my taste the new RM has not paid NEARLY enough
+attention to the critical requirement that no changes
+be made that are upwards incompatible.
+
+Now in practice, there are four cases
+
+1. The upwards incompatible change really makes sense
+and is really valuable as an addition to the language
+even though it is potentially painful. I would still
+have avoided such a change, but I see the argument. The
+only change in this category I am aware of is the
+NOT NULL change for parameters, and here the argument
+for symmetry with access types is very strong. On the
+other hand, changes like this that cause silent
+differences of behavior in Ada 95 and Ada 2005 mode
+are the worst kind possible, something we really worked
+hards to avoid in the Ada 95 design.
+
+2. The upwards incompatibility is a new feature which
+is valueable, but causes a very insigificant non-upwards
+compatibility that is easily tolerable. so small and trivial
+that we consider it insignificant. To me, adding new
+entities that are very unlikely to cause USE clashes
+is in this category. I find these acceptable.
+
+3. The upwards incompatibility is a real change, not
+mandated by the considerations of 1 of being valuable.
+Furthermore, it is a significant change that will
+be noticeable to users. For me there should be NOTHING
+in this category.
+
+4. The upwards incompatibility is a real change, not
+mandated by the considerations of 1 of being valuable,
+but it is such an insigificant change that we cannot
+imagine it being significantly troublesome or even
+noticeable to users.
+
+Now, what should be allowed in Ada 95:
+
+Case 1 is tough, the ARG has vacillated on this point
+with respect to allowing NOT NULL in Ada 95, and I
+understand why, since if you do not allow this to be
+put in Ada 95, you make it virtually impossible to
+maintain consistent code bases between Ada 95 and
+Ada 2005, which is very unfortunate. I think that
+if the ARG does not allow NOT NULL to be put in Ada 95,
+we will have to have a special mode in GNAT that is
+Ada 95 allowing this ONE extra significant new feature,
+and probably make that the default (we can make --pedantic
+enforce the standard, first time we used --pedantic but
+there is always a first time).
+
+Case 2 clearly does not warrant adding the feature to
+Ada 95, and remember the non-upwards incompatibility
+is insignificant, and there is no problem in the very
+unlikely event it is triggered of fixing sources to
+be compatible between the two modes.
+
+Case 3 should never happen. I don't want to talk about
+what you should do if it does.
+
+Case 4 is the case where I would allow the back port.
+For the record, you can make these binding interpretations.
+
+Odd that Tuck takes the formal view that he is not going
+to look at the merits of a case, only the formalistic
+issue of whether we have labeled it as a BI.
+
+OK, I amend my suggestion, instead of allowing this amazing
+new Ada 2005 feature (CE on null passed to Raise_Exception)
+to be optionally back ported to Ada 95, let's make it a
+binding interpretation and *require* it to be back ported.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, December  9, 2005  9:10 AM
+
+> The one case I remember discussing in the ARG meeting was allowing
+> "not null" to be added to "Ada 95" access parameters and
+> access discriminants with *no* semantic effect.  I was in
+> favor of this.  The ARG, based on a persuasive argument from
+> Pascal about portability, decided against this.  So I guess
+> I need a case that doesn't fall victim to Pascal's argument,
+> and at least for me, something involving a subtle change in
+> run-time semantics will have a much steeper hill to climb than
+> something that is "harmless" and compile-time related (though
+> it is hard for me to imagine something more benign than "not null").
+
+I don't believe that the Raise_Exception case has anything to
+do with portability, I think the only cases of programs running
+into this difference will be
+
+a) the ACATS test CB41004
+
+b) user programs with a bug, where Ada 2005 behavior is preferable
+
+If you think there are any cases of c:
+
+c) user programs that are making use of the possible return
+
+Then I think the feature change in Ada 2005 is gratuitous and
+should be withdrawn. Can you explain your justification for
+supporting this upwards incompatible change.
+
+I trust there was significant discussion of this in the ARG,
+as there must be any time the principle of avoiding non-upwards
+incompatible changes is violated.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, December  9, 2005  9:28 AM
+
+> Then I think the feature change in Ada 2005 is gratuitous and
+> should be withdrawn. Can you explain your justification for
+> supporting this upwards incompatible change.
+
+I have sent a reply twice now that has the explanation
+and justification, but it seems blocked somehow by the
+mailer.  I am hoping Randy can get it unstuck.
+
+> I trust there was significant discussion of this in the ARG,
+> as there must be any time the principle of avoiding non-upwards
+> incompatible changes is violated.
+
+There was a significant discussion of this on the ARG mailing
+list a year or two ago, and we ended up making different decisions
+for Raise_Exception and Raise_Occurrence, because this change
+was on the hairy edge of what is acceptable from the upward
+compatibility point of view.  Ultimately we concluded, if
+I remember correctly, that the existing semantics were well
+defined but error-prone, and hence made sense to change in the
+*next* version of the standard.  The semantics were not considered
+poorly defined or inconsistently implemented, which is the
+usual argument for a binding interpretation which changes the
+*existing* standard.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, December  9, 2005  9:48 AM
+
+There are many exceptions, the 7-8 bit character issue in Ada 83
+being perhaps the most notable, though there are many other places
+we have changed the language.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Saturday, December 10, 2005  4:45 AM
+
+> If we decide to change the semantics of something in Ada 95,
+> it will ripple unevenly and slowly, if at all, through the
+> various compilers out there.  And I just don't see the upside.
+
+I have to wonder if we are not in a deep pit already with respect to
+compatibility.
+
+About 5 years ago, we produced this document called Technical Corrigendum
+1.  I am pretty sure that it introduced quite a few silent changes.  It
+was never clear to me to what extent vendors implemented TC1 (we did most
+of it, but I seem to remember that I left aside one or two AIs that were
+annoying).  Furthermore, considering the number of certifications that
+took place over the last 5 years, it's hard to believe that the ACATS
+actually enforced a great deal of commonality.
+
+My point is that silent but minor changes to Ada 95 have probably trickled
+in implementations for some time.
+
+****************************************************************
+