CVS difference for ais/ai-00439.txt

--- ais/ai-00439.txt	2005/10/31 05:18:44	1.2
+++ ais/ai-00439.txt	2005/11/16 06:51:18	1.3
@@ -266,3 +266,279 @@
 
 ****************************************************************
 
+From: Gary Dismukes
+Sent: Thursday, November 10, 2005  6:58 PM
+
+This is really a policy question related to compilers supporting
+both Ada 95 and Ada 2005 features.  In some cases it seems we
+permit and even encourage compilers to implement Ada 2005 rule
+changes for Ada 95, but it's not always clear to me when that's
+the case.  The specific case I'm interested in at the moment
+is the rule change to E.2.3(14) that now effectively requires
+a limited type's stream attributes to be visible if the type
+is used for a formal of an RCI subprogram.  In Ada 95 the rules
+allowed such a formal even though the type's stream attributes
+were declared in the private part.  The rule change fixes a
+contract model problem, but it's an incompatible change.
+
+Is this a case where it's fine for a compiler to enforce the
+new rule when compiling for Ada 95?  I would think so, but
+I'm unsure and would like to hear what the policy is for this
+sort of change.  In other words, is this considered a bug fix,
+in which case Ada 95 compilers should enforce the rule change,
+or is it just an improvement and compilers with an Ada 95 mode
+should continue to support the Ada 95 version of the rule?
+
+I should mention that this change affects test BXE2009, which
+has a test case that conforms to the Ada 95 rule, so that test
+will need to be fixed.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, November 10, 2005  9:23 PM
+
+> Is this a case where it's fine for a compiler to enforce the
+> new rule when compiling for Ada 95?
+
+If the rule change was in a binding interpretation, the answer would be
+clear (Ada 95 compilers are expected to conform to the new interpretation).
+But for AIs of class Amendment, the answer is not clear. Well, actually, the
+answer *is* clear, in the absence of a new policy statement: Ada 95
+compilers are not affected. But that may not be what we want.
+
+> I would think so, but
+> I'm unsure and would like to hear what the policy is for this
+> sort of change.  In other words, is this considered a bug fix,
+> in which case Ada 95 compilers should enforce the rule change,
+> or is it just an improvement and compilers with an Ada 95 mode
+> should continue to support the Ada 95 version of the rule?
+
+I don't think we have such a policy. AI-439 (which is on the agenda for
+Atlanta) is intended to give one (but it is more narrow as written, only
+allowing new subprograms and packages).
+
+It may make sense to handle such issues (outside of new subprograms and
+packages) on a case-by-case basis, as it generally means that an AI is
+mis-categorized. That usually happens when part of an AI ought to be a BI,
+and part ought to be an Amendment.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, November 11, 2005  7:26 AM
+
+I would presume that Ada compilers, unless given some
+kind of "-2005" switch, should not start enforcing rules
+that are incompatible with Ada 95.  I can see them easing
+rules to allow flexibility, such as allowing "not null" but
+effectively ignoring.  But *requiring* that stream
+attributes be visible seems inappropriate.  I suppose
+you could start providing "friendly" warnings when
+code will become illegal under Ada 2005, but I don't
+see the need to jump the gun.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Friday, November 11, 2005  2:08 PM
+
+> This is really a policy question related to compilers
+> supporting both Ada 95 and Ada 2005 features.
+
+As usual, in a non-standard mode a compiler can do what it likes.
+
+In standard mode however, you have two choices: either you support
+8652:1995+TC1 or you support 8652:1995+TC1+AMD1.  You don't get to add a
+random collection of Ada 2005 features to your Ada 95 compiler.
+
+I don't think that the distinction between Binding Interpretation and
+Amendment AIs is relevant here because the BIs really have no teeth unless
+they are approved by the ISO chain of command, and such an approval will
+only take place as part of AMD1.  So I disagree with Randy when he claims
+that the BIs are somehow changing Ada 95.  The BIs are part of the
+definition of Ada 2005, period.
+
+Anyway, this is an important topic, and I have put it on the agenda for
+the next meeting.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, November 11, 2005  5:05 PM
+
+> I don't think that the distinction between Binding Interpretation and
+> Amendment AIs is relevant here because the BIs really have no teeth unless
+> they are approved by the ISO chain of command, and such an approval will
+> only take place as part of AMD1.  So I disagree with Randy when he claims
+> that the BIs are somehow changing Ada 95.  The BIs are part of the
+> definition of Ada 2005, period.
+
+I disagree with this pretty strongly, and feel that it attempts to
+significantly change the understanding of the ARG/WG9 process that
+has been in place for over twenty years.
+
+A BI can perfectly well change the meaning of the Ada standard, they
+are clarifications, and since the beginning of Ada time, we have always
+taken the view that WG9 approved BI AI's do in fact change the language
+(tecnically, they clarify an unclear point). Clarifying the meaning of
+the standard is well within WG9's authority, in fact it is one of its
+main jobs, and approval higher up the chain for such interpretations
+is neither required nor even customary, unless some formal document
+(like the amendment) is produced.
+
+So for example, though it is clear that the Ada 83 standard did not
+have any static subtypes, due to a wording error, in practice, WG9
+quickly ruled this an error, and fixed the language (all compilers
+had done it as expected anyway), and no WG9 approval was required.
+
+Now how far can you go in actually changing the language? Well it
+is a matter of taste. For Ada 83, we added 8-bit characters, which
+was a pretty big change, approved only by WG9, no higher, and many
+(most? all?) Ada 83 compilers adapted to this decision.
+
+So I don't think it is right to argue points like this on the
+general principle of whether such a change is allowable. Instead,
+each case needs to be considered individually. For me this particular
+issue is a close call, but I would be inclined not to allow the
+change to Ada 95 here.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, November 11, 2005  5:28 PM
+
+> A BI can perfectly well change the meaning of the Ada standard, they
+> are clarifications, and since the beginning of Ada time, we have always
+> taken the view that WG9 approved BI AI's do in fact change the language
+> (tecnically, they clarify an unclear point). Clarifying the meaning of
+> the standard is well within WG9's authority, in fact it is one of its
+> main jobs, and approval higher up the chain for such interpretations
+> is neither required nor even customary, unless some formal document
+> (like the amendment) is produced.
+
+I agree very much with Robert here. BIs have traditionally caused
+*immediate* changes in the ACVC. I've been slower with changes to the ACATS
+for a number of reasons (budget being one of them), but certainly any WG9
+approved BI is a candidate for an Ada 95 ACATS test.
+
+We can agree to *change* this policy (although I can't think of any good
+reason to do so), but certainly it is the policy.
+
+As Robert says, BIs are about fixing unclear or wrong parts of the language.
+Requiring compilers to do things that are clearly wrong is
+counterproductive, to say the least.
+
+So, in my view, the decision of how to handle a particular change should be
+made when the AI is(was) classified. If it is a BI, it applies to Ada 95 as
+well as Ada 2005; if it is "Amendment", it applies only to Ada 2005. If
+there are cases that are misclassified (and I can believe that), we need to
+fix them.
+
+...
+> So I don't think it is right to argue points like this on the
+> general principle of whether such a change is allowable. Instead,
+> each case needs to be considered individually. For me this particular
+> issue is a close call, but I would be inclined not to allow the
+> change to Ada 95 here.
+
+The case in question is classified as "Amendment", so we aren't
+allowing/expecting the change for Ada 95. (I view that as the default
+position, as noted above.) In this case, I think the change should have been
+classified as BI (and required for Ada 95 as well); but other parts of the
+same AI shouldn't be part of Ada 95. Splitting the AI probably is too much
+messing around, so I'd probably lean toward the status quo.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, November 11, 2005  5:31 PM
+
+> The case in question is classified as "Amendment", so we aren't
+> allowing/expecting the change for Ada 95. (I view that as the default
+> position, as noted above.) In this case, I think the change should have been
+> classified as BI (and required for Ada 95 as well); but other parts of the
+> same AI shouldn't be part of Ada 95. Splitting the AI probably is too much
+> messing around, so I'd probably lean toward the status quo.
+
+Yes, that's pretty much exactly the way I feel on this issue
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Monday, November 14, 2005  3:40 PM
+
+> So, in my view, the decision of how to handle a particular change should be
+> made when the AI is(was) classified. If it is a BI, it applies to Ada 95 as
+> well as Ada 2005; if it is "Amendment", it applies only to Ada 2005. If
+> there are cases that are misclassified (and I can believe that), we need to
+> fix them.
+
+That's always been my view as well, that a BI effectively applies to
+the current standard (once approved by WG9).
+
+> The case in question is classified as "Amendment", so we aren't
+> allowing/expecting the change for Ada 95. (I view that as the default
+> position, as noted above.) In this case, I think the change should have been
+> classified as BI (and required for Ada 95 as well); but other parts of the
+> same AI shouldn't be part of Ada 95. Splitting the AI probably is too much
+> messing around, so I'd probably lean toward the status quo.
+
+Umm, which AI are you referring to?  If you're talking about AI-240,
+which I think is the AI that most directly relates to question asked,
+that AI is classified as a BI (AI-195 also has a connection, but that's
+also a BI).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 14, 2005  5:14 PM
+
+> Umm, which AI are you referring to?  If you're talking about AI-240,
+> which I think is the AI that most directly relates to question asked,
+> that AI is classified as a BI (AI-195 also has a connection, but that's
+> also a BI).
+
+AI-366. The issue in question is whether the limited attributes have to be
+visible, and the definition of "external streaming" makes that a
+requirement. "Availability" (at least in the TC sense) do not make such a
+requirement.
+
+I suppose you could combine the two BIs (195 and 240) to get the result you
+want, but given that 195 was written without any consideration of the
+consequences in Annex E, that seems a bit dubious.
+
+I can certainly agree that this case is not clear cut, given that there are
+two different AIs that change the paragraph in question, and they have two
+different classifications. I suppose that will happen elsewhere in the
+standard as well. I suppose that means that we have no choice but to write
+and consider an AI on whether your question is a BI or Amendment (and thus
+whether it applies to Ada 95 compilers). [That's assuming that the
+meta-discussion results in the status-quo for that.] As such, you are
+assigned to write one by the deadline for this meeting (which was 6 minutes
+ago :-).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 14, 2005  5:24 PM
+
+> I suppose you could combine the two BIs (195 and 240) to get the result you
+> want, but given that 195 was written without any consideration of the
+> consequences in Annex E, that seems a bit dubious.
+
+I should clarify this by saying that this is dubious because nowhere is
+there any discussion of the incompatibility that results from this
+combination of AIs. Certainly, a BI should not be introducing
+incompatibilities without a clear discussion of them.
+
+AI-240 does mention "visibility issues", so it seems to have been written
+with a sense that Ada 95 was simply wrong. As was AI-195; neither can really
+be BIs because of the incompatibilities that they introduce.
+
+Anyway, we'll need to discuss this, and determine (a) if the rule in
+question is from AI-240 & 195, or from AI-366, and (b) if the
+incompatibility is actually OK in a BI.
+
+****************************************************************
+