Version 1.6 of ais/ai-00240.txt

Unformatted version of ais/ai-00240.txt version 1.6
Other versions for file ais/ai-00240.txt

!standard E.2.2 (8)          02-05-09 AI95-00240/04
!standard E.2.2 (14)
!standard E.2.3 (14)
!class binding interpretation 00-10-04
!status Amendment 200Y 02-07-09
!status WG9 Approved 02-06-21
!status ARG Approved 7-0-1 01-10-07
!status work item 00-10-04
!status received 00-10-04
!reference AI95-00195
!qualifier Clarification
!priority Low
!difficulty Medium
!subject Stream attributes for limited types in Annex E
!summary
E.2.2(14) and E.2.3(14) should allow any type with available Read and Write stream attributes.
!question
The Technical Corrigendum changed 13.13.2(36/1) to allow calls to stream attributes for limited type extensions where the attribute was specified for an ancestor type:
An attribute_reference for one of these attributes is illegal if the type is limited, unless the attribute has been specified by an attribute_definition_clause or [(for a type extension)] the attribute has been specified for an ancestor type.
Several paragraphs in Annex E require the existence of stream attributes for a type: E.2.2(8), E.2.2(14/1), and E.2.3(14/1). None of these paragraphs have been updated to reflect the previous change. Should any of them be updated? (Yes for E.2.2(14), E.2.3(14), No for E.2.2(8)).
!recommendation
(See summary.)
!wording
AI95-00195 makes a further change in 13.13.2(36/1), introducing the idea of a stream-oriented attribute being "available". This change makes it easier to word the replacement paragraphs.
Change E.2.2(8) to use the phrase "specified by a visible attribute_definition_clause" as "user-specified attribute" is not defined and ignores visibility issues.
Change E.2.2(14/1) to say "each non-controlling formal parameter shall have either a nonlimited type or a type with available Read and Write stream attributes;"
Change E.2.3(14/1) to say "...or a formal parameter of a limited type unless that limited type has available Read and Write stream attributes;"
!discussion
Let's consider each paragraph separately.
For E.2.2(8):
if the full view of a type declared in the visible part of the library unit has a part that is of a non-remote access type, then that access type, or the type of some part that includes the access type subcomponent, shall have user-specified Read and Write attributes.
The intent of this paragraph is stated in AARM E.2.2(8.a): to avoid the use of the default implementation of the attributes. Thus, we do not want to include the new case here (as it potentially uses a default implementation for extension components). The wording should, however, be corrected to use the phrase "specified by a visible attribute_definition_clause", so that visibility issues are included, and a defined phrase is used rather than the vague "user-specified" wording.
E.2.2(14/1) says:
The primitive subprograms of the corresponding specific limited private type shall only have access parameters if they are controlling formal parameters; each non-controlling formal parameter shall have either a nonlimited type or a type with Read and Write attributes specified via an attribute_definition_clause;
The intent of this paragraph is that the attributes be available (see the Defect Report 8652/0083 for a discussion). Thus, it echoes the original 13.13.2(36/1). However, with the change to 13.13.2(36/1), this does not allow the use of type whose attributes were specified for an ancestor type. Thus, this should be changed to match 13.13.2(36/1).
E.2.3(14/1) says:
it shall not be, nor shall its visible part contain, a subprogram (or access-to-subprogram) declaration whose profile has an access parameter, or a formal parameter of a limited type unless that limited type has user-specified Read and Write attributes;
This paragraph has the same intent as E.2.2(14/1). Thus, the wording should be similar.
!corrigendum E.2.2(8)
Replace the paragraph:
by:
!corrigendum E.2.2(14/1)
Replace the paragraph:
by:
!corrigendum E.2.3(14/1)
Replace the paragraph:
by:
!ACATS test
An ACATS test is needed to verify that the new cases are implemented properly.
!appendix

From: Randy Brukardt
Sent: Wednesday, October 04, 2000 2:26 PM

The Technical Corrigendum changes 13.13.2(36/1) to allow calls to stream
attributes for limited type extensions where the attribute was specified for
an ancestor type:
    An attribute_reference for one of these attributes is illegal if the
    type is limited, unless the attribute has been specified by an
    attribute_definition_clause or [(for a type extension)] the attribute has
    been specified for an ancestor type.

Several paragraphs in Annex E require the existence of stream attributes for
a type: E.2.2(8), E.2.2(14/1), and E.2.3(14/1). None of these paragraphs
have been updated to reflect the previous change.

For E.2.2(8):
   if the full view of a type declared in the visible part of the
   library unit has a part that is of a non-remote access type, then
   that access type, or the type of some part that includes the access type
   subcomponent, shall have user-specified Read and Write attributes.

The intent of this paragraph is stated in E.2.2(8.a): to avoid the use of
the default implementation of the attributes. Thus, we do not want to
include the new case here (as it potentially uses a default implementation
for extension components). I'm not sure if this paragraph is intended to
allow the use of inherited user-defined attributes, as it does not use the
magic wording "specified by an attribute_definition_clause" (which is
specifically defined to include inherited user-defined routines). It
definitely does not include the use of attribute of type extensions which
has an ancestor with an inherited user-defined attribute, as that
technically is a "default implementation" -- and that is what we want.

E.2.2(14/1) says:
  The primitive subprograms of the corresponding specific limited private type
  shall only have access parameters if they are controlling formal parameters;
  each non-controlling formal parameter shall have either a nonlimited type or
  a type with Read and Write attributes specified via an
  attribute_definition_clause;

The intent of this paragraph is that the attributes be callable (see the
Defect Report 8652/0083 for a discussion). Thus, it echoes the original
13.13.2(36). However, with the change to 13.13.2(36), this does not allow
the use of type whose attributes were specified for an ancestor type. It
seems that this should be changed to match 13.13.2(36). [If that is done, it
may be best to define a term "callable stream attribute" in 13.13.2(36), and
then use that here, to avoid synchronization problems in the future.]

E.2.3(14/1) says:
  it shall not be, nor shall its visible part contain, a subprogram (or
  access-to-subprogram) declaration whose profile has an access parameter, or
  a formal parameter of a limited type unless that limited type has
  user-specified Read and Write attributes;

The intent of this paragraph is not given anywhere. It seems to me that the
intent is similar to that of E.2.2(14). Thus, it is strange that the wording
differs so much; it seems to not allow any inherited user-specified
attributes, and definitely does not allow attributes of type extensions
which has an ancestor with an inherited user-defined attribute. Therefore,
the wording of this item should be changed in the same way that E.2.3(14/1)
is.

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

From: Robert A. Duff
Sent: Tuesday, January 3, 2006 12:30 PM

13.13.2 says:

                         Wording Changes from Ada 95

    61.r/1 {AI95-00366-01} Defined supports external streaming to put all of
          the rules about "good" stream attributes in one place. This is used
          for distribution and for defining pragma Pure.

and E.2.3 says:

                         Wording Changes from Ada 95

    20.c/2 {AI95-00240-01} {AI95-00366-01} Changed the wording to use the
          newly defined term type that supports external streaming, so that
          various issues with access types in pure units and implicitly
          declared attributes for type extensions are properly handled.

but this is an incompatibility (at least in part), not just a Wording Change.
So it should be listed as an incompatibility in the AARM.

For example, ACATS test bxe2009 says (in package spec BXE2009):

  procedure Has_Ok_Limited (P : Is_Limited_With_Attrs);              -- OK.

This line is legal in Ada 95, but illegal in Ada 2005, because the type
Is_Limited_With_Attrs has Read/Write attributes, but they are not visible at
this place.

E.2.3(14/2) requires the type to support external streaming.

"Support external streaming" is defined in 13.13.2(53/2),
in terms of streaming attrs being "available".

"Available" is defined for such attributes in 13.13.2(39/2).

I don't know if there is a corresponding incompatibility related to pragma
Pure.

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

From: Randy Brukardt
Sent: Tuesday, January 3, 2006  1:51 PM

> So it should be listed as an incompatibility in the AARM.

The change to "external streaming" from "available" was semantically
neutral.

> For example, ACATS test bxe2009 says (in package spec BXE2009):
>
>   procedure Has_Ok_Limited (P : Is_Limited_With_Attrs);
>    -- OK.
>
> This line is legal in Ada 95, but illegal in Ada 2005, because the type
> Is_Limited_With_Attrs has Read/Write attributes, but they are not
> visible at
> this place.

No, this line is not legal Ada 95; AI-240 (which is a Binding
Interpretation) changes E.2.3(14) to use "available" rather than the
original wording. So the attributes have to be visible in order for this to
work.

We don't have a category to document changes to the original Ada 95 which
are incompatible with that original definition but are considered
corrections to it (thus the original definition is gone, and any compiler
that follows it is wrong). You've pointed out a number of these, and I admit
that it is confusing that they're not documented in some way.

Any suggestions as to how to document these cases??

> I don't know if there is a corresponding incompatibility related to pragma
> Pure.

Yes, and that's documented in 10.2.1(28.e/2).

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

From: Robert A. Duff
Sent: Tuesday, January 3, 2006  5:21 PM

> No, this line is not legal Ada 95; AI-240 (which is a Binding
> Interpretation) changes E.2.3(14) to use "available" rather than the
> original wording. So the attributes have to be visible in order for this to
> work.

OK, thanks.

But what about that ACATS test?  Its existence seems to indicate that nobody is
obeying AI-240.

> We don't have a category to document changes to the original Ada 95 which
> are incompatible with that original definition but are considered
> corrections to it (thus the original definition is gone, and any compiler
> that follows it is wrong). You've pointed out a number of these, and I admit
> that it is confusing that they're not documented in some way.
>
> Any suggestions as to how to document these cases??

You could systematically go through all the binding interps,
and add annotations to the AARM at the places where they caused
wording changes.

But that's probably too much work.  It's a lot easier to tell people that if
they care about these issues, they have to search the AI's.

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

From: Pascal Leroy
Sent: Thursday, January 3, 2006  4:41 AM

> But what about that ACATS test?  Its existence seems to
> indicate that nobody is obeying AI-240.

You mean "nobody among the many vendors who support Annex E", right?

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

From: Robert A. Duff
Sent: Thursday, January 3, 2006  12:32 PM

ight.  ;-)

We found this at AdaCore while implementing and testing Ada 2005 mode.
We didn't realize this part of the stream changes are BI.

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


Questions? Ask the ACAA Technical Agent