Version 1.4 of 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 ... --
end P;
with P;
package P2 is
type T2 is new P.T with ...
for T2'Op use ... --
end;
with P, P2;
package P3 is
type New_T is new T with private;
--
private
type New_T is new T2 with ...;
--
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