Version 1.4 of ais/ai-00444.txt

Unformatted version of ais/ai-00444.txt version 1.4
Other versions for file ais/ai-00444.txt

!standard 13.1(15.1)          06-02-24 AI95-00444/02
!standard 13.13.2(8.1)
!standard 13.13.2(25)
!standard 13.13.2(41)
!class binding interpretation 05-12-08
!status Amendment 200Y 06-01-04
!status WG9 Approved 06-06-09
!status work item 05-12-05
!status received 05-12-05
!subject Streaming of untagged types
!summary
(See recommendation.)
!question
1 - At the Atlanta meeting it was noted that 13.13.2(8.1) was talking about the default implementation of stream attributes, when in fact there is no default implementation. The attributes are specified according to 13.1(17-18). In addition, while 13.1(15.1) talks about "inheritance" of operational attributes, this notion is not clearly defined for attributes that are subprograms. So it was proposed to rephrase 13.13.2(8.1) in terms of "invoking the attribute of the parent" instead of using an inheritance rule. But this leads to an incompatibility: if the attribute of the parent is specified after the derivation, 13.1(15.1) says that it is not inherited. But a wording based on "invoking" would imply that it is called (there is only one attribute of the parent type; there aren't different attributes for different views -- after all, if you can call it, the type is frozen and the attribute can't be changed).
2 - Furthermore, when studying this topic the following issues were encountered:
2.1 - The availability rules don't mention the case of limited derived untagged types. Surely the stream attributes should be available (at least under some circumstances) since 13.1(15.1) explain that they are inherited.
2.2 - The dynamic semantic rules of 13.13.2(8.1-9) should only apply to attributes that are available. We surely don't want to talk about inheriting or invoking the default Write attribute for a task type, since we have no idea what it does. After all, that why we invented the notion of availability: so that we don't have to describe the dynamic semantics of attributes that don't make any sense.
2.3 - When an subprogram aspect is inherited, what happens to the parameters isn't specified. We want something like the derived subprogram rules to apply. In addition, there is a privacy leak here; an attribute specified but that is not visible shouldn't be inherited.
!recommendation
1 - 13.13.2(8.1) is rephrased to use inheritance without talking about default implementation. A similar change is needed in 13.13.2(25).
2.1 - A rule must be added to make attributes of a limited derived untagged type T available if the attribute of the parent is available *at the place of the derivation*. Note the latter part of the rule: this location dependence is required to reflect 13.1(15.1): if the parent doesn't have a Read attribute at the place where T is declared, we don't want T'Read to be available anywhere, even if the parent has a subsequent attribute_definition_clause for Read. No such rule is needed in the tagged case because the record extension freezes the parent type.
2.2 - The introductory text in 13.13.2(8.1-9) is modified to make it clear that we only describe the dynamic semantics of available attributes. A similar change is needed in 13.13.2(25).
Add an AARM To be honest note: If the attributes are not available, we don't define what they do. They exist, but cannot be called, so what they do is irrelevant.
2.3 - In 13.1 we must explain what it means to inherit an attribute that is a subprogram, and do that by referring to 3.4. Presumably inheritance is self-explanatory for attributes that are objects or values, or for pragmas, but for subprograms there is some amount of mechanism going on.
We also must fix the privacy leak by requiring that the inherited aspect be visible.
!wording
(See Corrigendum.)
!discussion
For inheritance to occur, we require the operational item that directly specifies an aspect to be visible. We use "operational item" rather than "attribute_definition_clause" so that it is easy for implementers and future standards to define other kinds of operational items.
Inheritance is only defined for untagged derived types; otherwise, we could have an aspect defined differently for different views of a type. Assume that Op is a hypothetical operational attribute that is inherited for tagged types:
package P is type T is tagged ... for T'Op use ... -- Op(1) end P;
with P; package P2 is type T2 is new P.T with ... for T2'Op use ... -- Op(2) end;
with P, P2; package P3 is type New_T is new T with private; -- Op(1) inherited here. private type New_T is new T2 with ...; -- Op(2) inherited here. end P3;
The two views of New_T have inherited different implementations of the Op attribute. We don't allow this by 13.1(11/2), and we don't want arbitrary rules here.
Inheritance of tagged operational attributes doesn't make much sense anyway; we generally would want "incorporation" rather than "inheritance" as the extension components almost always need to participate. Moreover, no existing operational attributes need inheritance of tagged types, so we opt for the minimal fix and don't try to extend the model -- it can always be done if needed in the future.
!corrigendum 13.1(15.1)
Replace the paragraph:
In contrast, whether operational aspects are inherited by a derived type depends on each specific aspect. When operational aspects are inherited by a derived type, aspects that were directly specified before the declaration of the derived type, or (in the case where the parent is derived) that were inherited by the parent type from the grandparent type are inherited. An inherited operational aspect is overridden by a subsequent operational item that specifies the same aspect of the type.
by:
In contrast, whether operational aspects are inherited by an untagged derived type depends on each specific aspect. Operational aspects are never inherited for a tagged type. When operational aspects are inherited by an untagged derived type, aspects that were directly specified by operational items that are visible at the point of the derived type declaration, or (in the case where the parent is derived) that were inherited by the parent type from the grandparent type are inherited. An inherited operational aspect is overridden by a subsequent operational item that specifies the same aspect of the type.
When an aspect that is a subprogram is inherited, the derived type inherits the aspect in the same way that a derived type inherits a user-defined primitive subprogram from its parent (see 3.4).
!corrigendum 13.13.2(8.1)
Replace the paragraph:
For untagged derived types, the Write and Read attributes of the parent type are inherited as specified in 13.1; otherwise, the default implementations of these attributes are used. The default implementations of Write and Read attributes execute as follows:
by:
For an untagged derived type, the Write (resp. Read) attribute is inherited according to the rules given in 13.1 if the attribute is available for the parent type at the point where T is declared. For a tagged derived type, these attributes are not inherited, but rather the default implementations are used.
The default implementations of the Write and Read attributes, where available, execute as follows:
!corrigendum 13.13.2(25)
Replace the paragraph:
For untagged derived types, the Output and Input attributes of the parent type are inherited as specified in 13.1; otherwise, the default implementations of these attributes are used. The default implementations of Output and Input attributes execute as follows:
by:
For an untagged derived type, the Output (resp. Input) attribute is inherited according to the rules given in 13.1 if the attribute is available for the parent type at the point where T is declared. For a tagged derived type, these attributes are not inherited, but rather the default implementations are used.
The default implementations of the Output and Input attributes, where available, execute as follows:
!corrigendum 13.13.2(36)
!comment all of the paragraphs after 36 are new; this is 41 in draft 15.
@dinsa @xbullet<The @fa<attribute_designator> is Read (resp. Write) and @i<T> is a limited record extension, and the attribute Read (resp. Write) is available for the parent type of @i<T> and for the types of all of the extension components.> @dinst @xbullet<@i<T> is a limited untagged derived type, and the attribute was inherited for the type.>
!ACATS test
!appendix

From: Randy Brukardt
Sent: Wednesday, January  4, 2006  7:57 PM

As promised by the minutes, below is an AI that attempts to fix in a fairly
minimal way a number of issues noticed with streams after the Atlanta
resolutions.

This AI was drafted and redrafted by Pascal, Tucker, and I, and reflects the
majority consensus. We tried to make the minimum changes necessary to fix
the problems, as this is a Binding Interpretation (it primarily fixes
Corrigendum wording and other Binding Interpretations), and in any case it
is rather late to be rearranging the standard.

In the absence of strong objections, we intend to submit this as a formal
comment through one of the NBs.

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

Questions? Ask the ACAA Technical Agent