Version 1.4 of ais/ai-00439.txt

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.

****************************************************************