!standard 1.1.3 (06) 05-11-22 AI95-00439/02 !class binding interpretation 05-10-21 !status No Action (9-0-2) 05-11-19 !status work item 05-10-21 !status received 05-02-03 !priority High !difficulty Easy !subject Transitioning to Ada 2005 !summary Ada 95 compilers are allowed to include new subprograms and packages as defined by the Amendment. !question It will greatly ease implementation transition if we allow extra declarations in Ada 95 standard packages. Examples are allowing Wide_Wide_Character and Wide_Wide_String in Standard, the extra declaration in Ada.Strings, and the extra declarations in Ada.Characters. Is this allowed? (No.) !recommendation (See Summary.) !wording [Is there any wording? - ED] !discussion !ACATS test The effect of this AI is to potentially remove existing ACATS tests and prevent the introduction of new ones. !appendix From: Robert Dewar Sent: Thursday, February 3, 2005 11:39 AM It will greatly ease implementation transition if we allow extra declarations in Ada 95 standard packages. Examples are allowing Wide_String and Wide_Wide_String in Standard, the extra declaration in ada.strings, and the extra declarations in Ada.Characters.. Anyway, we should have a decision on this one way or another. There are three possibilities: 1. No, this is forbidden, and tests will be added to prevent it 2. Yes, it is allowed, and the AI will say it is allowed 3. It is allowed, but under a don't ask don't tell policy where we wont test for it ... Our current approach in GNAT is to 1. Disallow new Ada 2005 constructs if not in 2005 mode 2. Warn on use of Ada 2005 packages 3. Modify existing packages to be Ada 2005 compatible without any kind of warnings. If we decide on approach 1, then it's not too bad. I would add some special syntactic gizmo, allowed only in run-time files, that says that the rest of the line is to be ignored if not in Ada 2005 mode. **************************************************************** From: Randy Brukardt Sent: Thursday, February 3, 2005 1:01 PM > 3. It is allowed, but under a don't ask don't tell policy where > we wont test for it ... The ACAA's policy has been roughly (3). I've been removing test subcases that conflict with Ada 2005 (especially if they are in BIs), with the intent of reintroducing them, suitably modified, in a future Ada 2005 ACATS. We have not found many (although I expect more from AI-318). Vendors can help by pointing out tests that conflict. Certainly, there won't be ACATS tests to check if Wide_Wide_String or the overloaded Index routines in Ada.Strings have been introduced. That would be counterproductive, and we simply don't have the time nor money to develop such tests anyway. So I don't think that there is any practical chance of (1). It wouldn't hurt if the ARG adopted an official transition policy, but nothing fancy is needed. **************************************************************** From: Robert Dewar Sent: Thursday, February 3, 2005 1:18 PM > Certainly, there won't be ACATS tests to check if Wide_Wide_String or the > overloaded Index routines in Ada.Strings have been introduced. That would be > counterproductive, and we simply don't have the time nor money to develop > such tests anyway. So I don't think that there is any practical chance of > (1). Overloaded Index routines???? the word Index does not appear in AI-285, nor in the text of Ada.Strings??? DOn't tell me there is some secret additional list of things to do :-) **************************************************************** From: Randy Brukardt Sent: Thursday, February 3, 2005 2:40 PM I meant Ada.Strings.[Fixed|Bounded|Unbounded] - the packages that get used the most. That's in AI-301, and I thought that you were referring to those, rather trivial additions along with the ones from AI-285. Nothing secret about it; it's in the Amendment document. **************************************************************** From: Robert Dewar Sent: Thursday, February 3, 2005 7:11 PM OK, yes, fine, no problem, that makes perfectly good sense, and I agree these should be tolerated. I tool your statement about Ada.Strings too literally :-) **************************************************************** From: Pascal Leroy Sent: Friday, February 4, 2005 2:33 AM > Our current approach in GNAT is to > > 1. Disallow new Ada 2005 constructs if not in 2005 mode > > 2. Warn on use of Ada 2005 packages > > 3. Modify existing packages to be Ada 2005 compatible > without any kind of warnings. When Ada 95 was introduced our customers insisted that we keep supporting and implementing strictly the Ada 83 subset (not quite a subset, I know), so we didn't add any Ada 95-related feature to the compiler or predefineds when operating in Ada 83 mode. This was a portability concern: many of them were using another compiler which was supporting Ada 83, but maybe not Ada 95, or not the entire Ada 95. There is no reason to believe that things will be different this time, so we will keep supporting the strict Ada 95 subset (not quite a subset, I know), and we won't be adding any Ada 2005-related feature to the compiler or predefineds when operating in Ada 95 mode. To me, this is largely a business decision, and if IBM and AdaCore reach different conclusion as to whether Wide_Wide_Character should be added to Standard, it probably reflects different user communities. So to answer Robert's question, I think that (1) would be counter-productive, I'd much rather test important features of the new language; (2) would be a big mistake as it would confuse the users and potentially destabilize existing compiler technology; (3) is our best choice: we are no longer in the "no subset, no superset" dogma, and we want to allow implementers to do what is useful for their user community. **************************************************************** From: Robert Dewar Sent: Friday, February 4, 2005 9:08 AM > When Ada 95 was introduced our customers insisted that we keep supporting > and implementing strictly the Ada 83 subset (not quite a subset, I know), > so we didn't add any Ada 95-related feature to the compiler or predefineds > when operating in Ada 83 mode. This was a portability concern: many of > them were using another compiler which was supporting Ada 83, but maybe > not Ada 95, or not the entire Ada 95. Right, AdaCore also keeps pretty strict Ada 83 "subset", but indeed I don't think this is so much of a concern in the Ada 95 case, and I think warnings will be fine most of the time. Plus we really don't want two versions of things like Interfaces.C around, since this will cause a lot of confusion. On the other hand, marking new declarations with something like a prior line reading --Ada 2005 only-- in the run-time would be pretty easy to implement, so perhaps I will go ahead and do this. Not a bad idea for documentation in any case :-) > To me, this is largely a business decision, and if IBM and AdaCore reach > different conclusion as to whether Wide_Wide_Character should be added to > Standard, it probably reflects different user communities. I don't think the user communities are particular different (indeed many of our users are former Rational users) but I am not sure of Pascal's argument by analogy with legacy Ada 83 code is valid. But I agree this is reasonably left open as a business decision. It will be interesting to see what Greenhills does, they are notably absent from these discussions :-) The scenario for someone wanting strict Ada 83 is that they want to maintain compatibility with a compiler strictly implementing the old version. That's what we get with GNAT, people migrate to GNAT, but they want to maintain compatibility with an old compiler for Ada 83 from xyz company. The other use of the Ada 83 switch is from people who don't know Ada very well and are dealing with code that they know is Ada 83 code and just assume (usually incorrectly) that they are better off operating in Ada 83 mode. In practice, I think it is pretty unlikely that people will start using char32_t and Wide_Wide_Character (hmm I could stop this sentence right there) not knowing that this is an Ada 2005 feature, so I am not sure that these kind of legacy issues will apply with Ada 95, especially since the transition is going to be much more rapid. > So to answer Robert's question, I think that (1) would be > counter-productive, I'd much rather test important features of the new > language; (2) would be a big mistake as it would confuse the users and > potentially destabilize existing compiler technology; (3) is our best > choice: we are no longer in the "no subset, no superset" dogma, and we > want to allow implementers to do what is useful for their user community. OK, so no tests in the ACATS, and we deep six this thread :-) **************************************************************** From: Randy Brukardt Sent: Friday, February 4, 2005 1:09 PM > > So to answer Robert's question, I think that (1) would be > > counter-productive, I'd much rather test important features of the new > > language; (2) would be a big mistake as it would confuse the users and > > potentially destabilize existing compiler technology; (3) is our best > > choice: we are no longer in the "no subset, no superset" dogma, and we > > want to allow implementers to do what is useful for their user > community. > > OK, so no tests in the ACATS, and we deep six this thread :-) From the perspective of the ACAA, it would be nice to have a policy statement to this effect. ("We decide not to have a policy about transition; Ada 95 can implement Ada 2005 features if they wish. There should not be ACATS tests that check that Ada 95 compilers do not implement Ada 2005 features, and there should not be ACATS tests which require Ada 95 compilers to be incompatible with Ada 2005.") Or something like that. (It's usually best that I have on-the-record guidance about policy issues.) **************************************************************** From: Robert Dewar Sent: Friday, February 4, 2005 1:06 PM GIven Pascal's note on this issue, it seems good for me for compilers to adopt a similar strategy on the transiition, so following what I said before, I did implement a general mechanism to label declarations as Ada 2005 (with a pragma), and any use of any of these in Ada 95 mode will generate a warning (which we could decide should be an error later if we want). Easy enough to do, and can only be helpful in maintaining compatibility between different vendors compilers. **************************************************************** 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. **************************************************************** 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. ****************************************************************