!standard 1.1.3  (06)                                 05-10-21  AI95-00439/01
!class binding interpretation 05-10-21
!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_String and Wide_Wide_String in
Standard, the extra declaration in ada.strings, and the
extra declarations in Ada.Characters.

Is this allowed? (Yes.)

!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.

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