CVS difference for ai05s/ai05-0183-1.txt
--- ai05s/ai05-0183-1.txt 2011/03/17 07:14:05 1.22
+++ ai05s/ai05-0183-1.txt 2011/03/25 02:17:54 1.23
@@ -36,7 +36,7 @@
!standard 13.1(11/2)
!standard 13.1(15.1/2)
!standard 13.3(5/1)
-!standard 13.3(73.11/1)
+!standard 13.3(73.1/1)
!standard 13.3.1(0)
!standard 13.13.2(1/1)
!standard 13.14(7.1/2)
@@ -358,8 +358,8 @@
[type of the subtype]{entity} denoted by the local_name{, except in
the case of a type-related operational item, whose local_name shall
denote a first subtype, and which directly specifies an aspect of the
- subtype's type. [The local_name of an operational item shall denote a
- first subtype. An operational item that names a subtype is
+ type of the subtype. [The local_name of an operational item shall
+ denote a first subtype. An operational item that names a subtype is
type-related.]
Modify 13.1(9, 9.1/1) as follows:
@@ -409,7 +409,7 @@
aspect of representation{; the name of the aspect is that of the
attribute}.
-Modify 13.3(73.11/1) as follows:
+Modify 13.3(73.1/1) as follows:
The following {type-related} operational attribute is defined: External_Tag.
@@ -765,7 +765,7 @@
@dby
@xcode<@fa<object_declaration ::=
defining_identifier_list : [>@b<@ft<aliased>>@fa<] [>@b<@ft<constant>>@fa<] subtype_indication [:= expression]
- [aspect_specifocation];
+ [aspect_specification];
| defining_identifier_list : [>@b<@ft<aliased>>@fa<] [>@b<@ft<constant>>@fa<] access_definition [:= expression]
[aspect_specification];
| defining_identifier_list : [>@b<@ft<aliased>>@fa<] [>@b<@ft<constant>>@fa<] array_type_definitirn [:= expression]
@@ -1128,6 +1128,90 @@
13.3.1), which is an optional element of certain
kinds of declarations.
+!corrigendum 13.1(8.1/1)
+
+@drepl
+An operational item @i<directly specifies> an @i<operational aspect> of the
+type of the subtype denoted by the @fa<local_name>. The @fa<local_name> of an
+operational item shall denote a first subtype. An operational item that names
+a subtype is type-related.
+@dby
+An operational item @i<directly specifies> an @i<operational aspect> of the
+entity denoted by the @fa<local_name>, except in the case of a type-related
+operational item, whose @fa<local_name> shall denote a first subtype, and
+which directly specifies an aspect of the type of the subtype.
+
+!corrigendum 13.1(9)
+
+@drepl
+A representation item that directly specifies an aspect of a subtype or
+type shall appear after the type is completely defined (see 3.11.1), and
+before the subtype or type is frozen (see 13.14). If a representation item
+is given that directly specifies an aspect of an entity, then it is illegal
+to give another representation item that directly specifies the same aspect
+of the entity.
+@dby
+A representation item that directly specifies an aspect of a subtype
+or type shall appear after the type is completely defined (see
+3.11.1), and before the subtype or type is frozen (see 13.14). If a
+representation item or @fa<aspect_specification> is given that directly
+specifies an aspect of an entity, then it is illegal to give another
+representation item or @fa<aspect_specification> that directly specifies
+the same aspect of the entity.
+
+!corrigendum 13.1(9.1/1)
+
+@drepl
+An operational item that directly specifies an aspect of a type shall appear
+before the type is frozen (see 13.14). If an operational item is given that
+directly specifies an aspect of a type, then it is illegal to give another
+operational item that directly specifies the same aspect of the type.
+@dby
+An operational item that directly specifies an aspect of an entity shall
+appear before the entity is frozen (see 13.14).
+If an operational item or @fa<aspect_specification> is given that
+directly specifies an aspect of an entity, then it is
+illegal to give another operational item or @fa<aspect_specification>
+that directly specifies the same aspect of the entity.
+
+!corrigendum 13.1(11/2)
+
+@drepl
+Operational and representation aspects of a generic formal parameter are the
+same as those of the actual. Operational and representation aspects are the
+same for all views of a type. A type-related representation item is not allowed
+for a descendant of a generic formal untagged type.
+@dby
+Operational and representation aspects of a generic formal parameter
+are the same as those of the actual. Representation aspects are the same
+for all views of a type. If an operational aspect is specified for a partial
+view of a type, then it applies to the full view as well. A type-related
+representation item is not allowed for a descendant of a generic formal untagged
+type.
+
+!corrigendum 13.1(15.1/2)
+
+@drepl
+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.
+@dby
+In contrast, whether operational aspects are inherited by a derived type
+depends on each specific aspect; unless specified, an operational aspect is
+not inherited. When operational aspects are inherited by a 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.
+
+
!corrigendum 13.3(5/1)
@drepl
@@ -1144,6 +1228,13 @@
representation; the name of the aspect is that of the
attribute.
+!corrigendum 13.3(73.1/1)
+
+@drepl
+The following operational attribute is defined: External_Tag.
+@dby
+The following type-related operational attribute is defined: External_Tag.
+
!corrigendum 13.3.1(0)
@dinsc
@@ -1162,7 +1253,7 @@
@xcode<@fa<aspect_mark ::= >@i<@ft<aspect_>>@fa<identifier['>@ft<Class>@fa<]>>
-@xcode<@fa<aspect_definition ::= name | expression>>
+@xcode<@fa<aspect_definition ::= name | expression | identifier>>
@i<@s8<Name Resolution Rules>>
@@ -1226,9 +1317,97 @@
a tagged type or a primitive subprogram of a tagged type.
@i<@s8<Static Semantics>>
+
+Depending on which aspect is identified by the @fa<aspect_mark>, an
+@fa<aspect_definition> specifies:
+
+@xbullet<a @fa<name> that denotes a subprogram, object, or other kind of entity;>
+
+@xbullet<an @fa<expression>, which is either evaluated to produce a single
+value, or which (as in a precondition) is to be evaluated at
+particular points during later execution; or>
+
+@xbullet<an @fa<identifier> specific to the aspect.>
+
+The identified aspect of the associated entity, or in some cases, the
+view of the entity defined by the declaration, is as specified by the
+@fa<aspect_definition> (or by the default of True when boolean). Whether an
+@fa<aspect_specification> applies to an entity or only to the particular
+view of the entity defined by the declaration is determined by the
+@fa<aspect_mark> and the kind of entity. The following aspects are view specific:
+
+@xbullet<An aspect specified on an @fa<object_declaration>;>
+
+@xbullet<An aspect specified on a @fa<subprogram_declaration>;>
+
+@xbullet<The Address aspect;>
+
+@xbullet<An aspect specified on a @fa<renaming_declaration>.>
+
+Other @fa<aspect_specification>s are associated with the entity, and apply
+to all views of the entity, unless otherwise specified in this
+International Standard.>
+
+If the @fa<aspect_mark> includes 'Class, then:
+
+@xbullet<if the associated entity is a tagged type, the specification
+applies to all descendants of the type;>
+
+@xbullet<if the associated entity is a primitive subprogram of a tagged type @i<T>,
+the specification applies to the corresponding primitive subprogram of
+all descendants of @i<T>.>
+
+All specifiable operational and representation attributes may be
+specified with an @fa<aspect_specification> instead of an
+@fa<attribute_definition_clause> (see 13.3). The @fa<attribute_designator> is
+used for the @fa<aspect_mark>. In addition, certain other operational and
+representation aspects not associated with specifiable attributes may
+be specified, as specified elsewhere in this International Standard.
+In the case of aspects specifiable with pragmas, the pragma @fa<identifier>
+is used for the @fa<aspect_mark>, unless otherwise specified in this
+International Standard.
+
+If an aspect of a derived type is inherited from an ancestor type and
+has the boolean value True, the inherited value shall not be
+overridden to have the value False for the derived type, unless
+otherwise specified in this International Standard.
+
+There are no language-defined aspects that may be specified on a
+@fa<renaming_declaration> nor on a @fa<formal_type_declaration>.
+
+Alternative legality and semantics rules may apply for particular
+aspects, as specified elsewhere in this International Standard.
+
+@i<@s8<Dynamic Semantics>>
+
+At the freezing point of the associated entity, the @fa<aspect_specification> is
+elaborated. The elaboration of the @fa<aspect_specification> includes the
+evaluation of the @fa<name> or @fa<expression>, if any, unless the aspect itself is an
+@fa<expression>. If the corresponding aspect represents an @fa<expression> (as in a
+precondition), the elaboration has no effect; the @fa<expression> is evaluated
+later at points within the execution as specified elsewhere in this
+International Standard for the particular aspect.
+
+
+!corrigendum 13.13.2(1/1)
+
+@drepl
+The operational attributes Write, Read, Output, and Input convert values to a
+stream of elements and reconstruct values from a stream.
+@dby
+The type-related operational attributes Write, Read, Output, and Input convert
+values to a stream of elements and reconstruct values from a stream.
+
+!corrigendum 13.14(7.1/2)
-@i<@b<Rest of this text TBD>>
+@dinsa
+@xbullet<The declaration of a record extension, interface type, task unit, or protected
+unit causes freezing of any progenitor types specified in the declaration.>
+@dinst
+@xbullet<At the freezing point of the entity associated with an @fa<aspect_specification>,
+any @fa<expression>s or @fa<name>s within the @fa<aspect_specification> cause freezing.>
+
!example
(See discussion.)
@@ -5878,5 +6057,143 @@
****************************************************************
implementing semantic features.
+From: Randy Brukardt
+Sent: Thursday, March 17, 2011 11:32 AM
+
+I was think about the issue with giving the value of Priority for a main
+subprogram this morning, and a modest suggestion has come out of it.
+
+To remind everyone, the problem is that we don't allow aspect_specifications
+on subprogram bodies. Therefore, you have to give a separate specification
+in order use the aspect form to specify Priority; this led to leaving the
+pragma in the core rather than making it obsolescent.
+
+It strikes me that this problem occurs for pretty much any aspect that can
+be specified on a subprogram, not just the real-time ones. That includes Inline,
+No_Return, Pre, and Post. Specifying any of these requires giving a separate
+specification.
+
+In the case of subprogram library units (including main subprograms), it is
+unusual to give a separate specification.
+
+I am thinking that we ought to allow aspect_specifications to be given on
+bodies, so long as there is no specification. Formally, this would look like:
+
+Replace 6.3(2/2) by:
+
+subprogram_body ::=
+ [overriding_indicator]
+ subprogram_specification
+ [aspect_specification] is
+ declarative_part
+ begin
+ handled_sequence_of_statements
+ end [designator];
+
+Add to the end of 6.3(4) [Legality Rules]:
+
+If a subprogram_body is a completion, no aspect_specification shall be given.
+
+
+The legality rule ensures that each subprogram has precisely one
+aspect_specification, so we don't have to define conformance for
+aspect_specifications.
+
+Then, a main subprogram can look like:
+
+ procedure Do_It
+ with Priority => 8,
+ CPU => 1,
+ Post => Goodness = True is
+ begin
+
+ Get_Sweetness_and_Light;
+ end Do_It;
+
+Thoughts??
+
+****************************************************************
implementing semantic features.
+
+From: Tucker Taft
+Sent: Thursday, March 17, 2011 11:45 AM
+
+Makes sense to me.
+
+****************************************************************
implementing semantic features.
+
+From: Randy Brukardt
+Sent: Thursday, March 24, 2011 12:56 AM
+
+In the latest version of AI05-0183-1, Tucker changed 13.1(11/2):
+ Operational and representation aspects of a generic formal parameter
+ are the same as those of the actual. [Operational and
+ r]{R}epresentation aspects are the same for all views of a type. {If
+ an operational aspect is specified for a partial view of a type, then
+ it applies to the full view as well.} A type-related representation
+ item is not allowed for a descendant of a generic formal untagged
+ type.
+
+This wording seems to leave the value of operational aspects defined on
+full views undefined for the partial view. That would cause issues for
+stream attributes of a non-limited partial view where the attribute is
+specified for the full view:
+
+ package Fooey is
+ type Priv is private;
+ private
+ type Priv is ...
+ with Read => My_Read;
+ procedure Read (A : not null access Streams.Root_Stream_Type;
+ B : out Priv);
+ end Fooey;
+
+ with Fooey;
+ procedure Main is
+ P : Fooey.Priv;
+ begin
+ Fooey.Priv'Read (Some_Stream, P); -- ???
+ end Main;
+The original wording made it clear that the Read aspect has the same value
+for all views of the type. Thus, the attribute clearly calls the body of Read,
+even though that attribute definition is not visible.
+
+However, with the new wording, the value of the Read aspect is unspecified for
+the partial view. You might think that it has the default value of the aspect
+-- indeed, I can't find any reason to think anything else, other than that it is
+completely undefined - there is no mention of partial views when defining stream
+attributes 13.13.2 - in large part because 13.1(11/2) said that it isn't necessary.
+The only thing that doesn't make sense is to assume it is the specified aspect --
+since the wording does not say anything about the partial view when the full view
+is defined. This seems especially likely because the wording is different than
+the representation aspect case; one has to presume that is on purpose.
+
+I'm not sure why Tucker made this change, but I think it is a mistake to abandon
+the principle that a type-related aspect is the same for all views (and it definitely
+is a mistake in this case!). [I can't think of any reason that this would cause any
+problems with Type_Invariants -- they surely need to be the same for all views; you
+might not be able to *see* it, but I hope it still gets checked.] If there is a
+problem with visibility, it ought to be checked with Legality Rules, not some hack
+about the values.
+
+We either need to completely revert the change, or make it clear that type-related
+aspects have the same value for all views (letting the new wording only apply for
+other kinds of aspects, should they ever exist), or Tucker has to be a lot clearer
+about what he is trying to accomplish.
+
+****************************************************************
implementing semantic features.
+
+From: Randy Brukardt
+Sent: Thursday, March 24, 2011 1:33 AM
+
+It also conflicts with the wording already in AI05-0183-1 which defines aspects:
+
+ Other aspect_specifications are associated with the entity, and apply
+ to all views of the entity, unless otherwise specified in this
+ International Standard.
+
+Unless the intent is to change this for all type-related operational aspects --
+which is going too far IMHO.
+
+****************************************************************
implementing semantic features.
Questions? Ask the ACAA Technical Agent