CVS difference for ai12s/ai12-0427-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0427-1.txt

--- ai12s/ai12-0427-1.txt	2021/05/08 05:22:55	1.1
+++ ai12s/ai12-0427-1.txt	2021/05/24 22:56:13	1.2
@@ -1,4 +1,11 @@
-!standard 4.10(0/5)                                   21-05-07  AI12-0427-1/01
+!standard 4.10(0/5)                                   21-05-22  AI12-0427-1/02
+!standard 8.5(5)
+!standard 8.6(17.1/5)
+!standard 13.1(13.1/3)
+!standard 13.1.1(21/3)
+!standard 13.1.1(22/3)
+!standard 13.3(6)
+!standard 13.13.2(51/3)
 !class Amendment 21-05-07
 !status Amendment 1-2012 21-05-07
 !status work item 21-05-07
@@ -11,6 +18,16 @@
 (1) Add rules about the subtypes of Put_Image and the propagation of 
 exceptions from implicit calls to Put_Image.
 
+(2) Delete 8.5(5); it is not true in Ada 202x (and part of it was not true
+in Ada 2005 or Ada 2012, either).
+
+(3) Add "unless otherwise specified" to the second sentence of 8.6(17.1/5).
+
+(4) Add a case for "aggregates" to 13.1.1(19-22/3).
+
+(5) Generalize 13.3(6) (moving it after 13.1(13.1/3)) and 13.13.2(51/3) to
+apply to aspect_specifications as well as attribute_definition clauses.
+
 !problem
 
 (1) Stream-oriented attributes define the subtype of the parameter of the 
@@ -23,10 +40,53 @@
 propagate any exceptions (including those caused by a subtype check
 failure).
 
+(2) 8.5(5) says that an object of an anonymous access type cannot be renamed. 
+However, it seems to me that the second alternative in 8.5.1(1/5), the 
+"access_definition" case, does allow such a renaming. Similarly, 8.5(5) says
+that a single task or protected object cannot be renamed since the 
+corresponding type is anonymous, but as we can now omit the subtype_mark 
+from the object_renaming_declaration, it seems that such entities can be 
+renamed. Either I am wrong, or the statements in 8.5(5) are wrong.
+
+(3) The nominal (sub)type specified in 8.6(17.1/5) for the "current instance"
+value seems to be overridden in 7.3.2(5/4) for the aspect 
+Type_Invariant'Class, and in 7.3.3(4/5) for the aspect 
+Default_Initial_Condition, where different types ("NT") are specified for the
+current instance. This apparent contradiction should be addressed in some way.
+
+(4) In RM 13.1.1(19/3-22/3) we have:
+
+Depending on which aspect is identified by the aspect_mark, an
+aspect_definition specifies:
+
+  * a name that denotes a subprogram, object, or other kind of entity;
+  * an 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
+  * an identifier specific to the aspect.
+
+This is relatively old wording, and doesn't mention "aggregate" which is of
+course a kind of expression, but in newer wording is called out separately,
+and it is certainly misleading to talk about it being evaluated to produce a
+"single value."
+
+(5) Paragraphs 13.3(6) and 13.13.2(51/3) give requirements on subprograms 
+specified for attributes (aspects) via an attribute_definition_clause. There
+is no rule that does that for aspects specified via aspect_specifications.
+
 !proposal
 
 (1) Add appropriate wording.
 
+(2) Delete 8.5(5).
+
+(3) Add "unless otherwise specified" to the second sentence of 8.6(17.1/5).
+
+(4) Add an extra bullet for "aggregates".
+
+(5) Generalize 13.3(6) (moving it after 13.1(13.1/3)) and 13.13.2(51/3) to
+apply to aspect_specifications as well as attribute_definition clauses.
+
 !wording
 
 (1) Add after 4.10(4/5):
@@ -49,17 +109,211 @@
 attempt to do that here, either. All such wording is redundant, since it
 follows directly from the definition of exception propagation in 11.4.]
 
+(2) Delete 8.5(5).
+
+(3) Modify 8.6(17.1/5):
+
+Within an aspect_specification for a type or subtype, the current instance 
+represents a value of the type; it is not an object. {Unless otherwise 
+specified, the}[The] nominal subtype of this value is given by the subtype
+itself (the first subtype in the case of a type_declaration), prior to 
+applying any predicate specified directly on the type or subtype. If the
+type or subtype is by-reference, the associated object of the value is the
+object associated (see 6.2) with the evaluation of the usage name.
+
+(4) Modify 13.1.1(21/3):
+
+  * an expression{ (other than an aggregate)}, 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]
+
+Modify 13.1.1(22/3):
+
+  * an identifier specific to the aspect{; or
+  * an aggregate, which is positional or named, and is composed of elements of
+    any of these four kinds of constructs}.
+
+(5) Add after 13.1(13.1/3):
+
+When specifying an aspect that denotes a subprogram, the profile of the 
+subprogram shall be mode conformant with the one required for the aspect,
+and the convention shall be Ada. Additional requirements are defined for
+particular aspects. 
+
+AARM Ramification: As well as applying to aspect_specifications, this rule
+applies to attribute_definition_clauses for those aspects that have associated 
+attributes.
+
+This rule implies, for example, that if one writes: 
+
+    type T is ...
+       with Read => R;
+
+R has to be a procedure with two parameters with the appropriate subtypes and
+modes as shown in 13.13.2. 
+End AARM Ramification.
+
+[Editor's note: The latter half of this AARM Ramification is from the existing
+text, modified to use an aspect_specification.]
+
+Delete 13.3(6) and the associated notes (the rule above replaces it).
+
+Modify 13.13.2(51/3):
+
+For an attribute_definition_clause {or aspect_specification} specifying one of 
+these attributes, the subtype of the Item parameter shall be the first subtype 
+or the base subtype if scalar, and the first subtype if not scalar. The same
+rule applies to the result of the Input function.
+
+Modify AARM 13.13.2(51.b/3):
+
+The view of the type at the point of the attribute_definition_clause determines 
+whether the base subtype is allowed. Thus, for a scalar type with a partial view
+(which is never scalar), whether the base subtype is allowed is determined by 
+whether the attribute_definition_clause occurs before or after the full 
+definition of the scalar type.{ For the same reason, the base subtype is never 
+allowed for an attribute specified via an aspect_specification on the partial 
+view.}
+
 !discussion
 
-(1) The first paragraph is modeled on that found in 13.13.2(51/3) fo
- stream-oriented attributes. The second paragraph is modeled on
+(1) The first paragraph is modeled on that found in 13.13.2(51/3) for
+stream-oriented attributes. The added sentences are modeled on 
+13.11(21.5/3) for calls to Allocate.
+
+Note that we don't consistently mention exception propagation in the RM; 
+such wording is not needed since the definition of exception propagation in
+11.4 clearly covers that (it's not limited to particular constructs). For
+example, we have exception propagation wording for calls to Allocator in
+allocators, but we have no such wording for calls to Deallocation from
+Unchecked_Deallocation. As such, we only added it in a few cases where it
+was easy and did not disrupt the flow of the text.
+
+(2) We could try to rewrite the note to make it True. However, this note is
+in the introductory material for renaming, so it should not be very detailed.
+Moreover, the original purpose clearly is to note that not all objects can be
+renamed -- but all objects (and many values as well) CAN be renamed in 
+Ada 202x, so any revised note is not longer serving that purpose. The notion
+that not all constructs can be used in all possible ways seems fundamental to
+a programming language, and the RM does not need notes to give out random
+facts (especially in the general overview material). Thus we recommend 
+deleting this note.
+
+If there is felt to be value in a revised note, the Editor would suggest that
+such a note would be more appropriate in 8.5.1 (details of object renaming)
+rather than in the overview material of 8.5.
+
+(3) As noted in the !problem, 7.3.2(5/4) and 7.3.3(4/5) specify a different
+subtype, so we should make it clear that this rule can be overridden by a
+more specific rule.
+
+(4) An aggregate is composed of all of the other kinds of things, and might
+be evaluated piece-meal. As such, it is best to handle them separately.
+
+(5) While there can be no doubt of the intent of an equivalence between
+specification via an aspect_specification and an attribute_definition_clause,
+we have been trying to eliminate semantic rules that specifically
+mention how some aspect/attribute is specified, since those can be misread
+easily and are always confusing. 
+
+The rule of 13.3(6) (which is associated with the description of 
+attribute_definition_clauses) should be moved to 13.1 (which contains rules 
+that apply to all aspects). There are no other rules that apply to all aspects
+in 13.3; this is an unusual place that even Ada experts have difficulty 
+finding.
 
+The author checked the entire AARM for uses of attribute_definition_clause,
+and did not find any other rules that needed generalization.
 
 !corrigendum 4.10(0)
 
 @dinsc
 See the conflict file for the changes.
 
+!corrigendum 8.5(5)
+
+@ddel
+10  A task or protected object that is declared by an explicit
+@fa<object_declaration> can be renamed as an object. However, a single task
+or protected object cannot be renamed since the corresponding type is 
+anonymous (meaning it has no nameable subtypes). For similar reasons, an 
+object of an anonymous array or access type cannot be renamed.
+
+!corrigendum 8.6(17.1/5)
+
+@drepl
+@xindent<Within an @fa<aspect_specification> for a type or subtype, the
+current instance represents a value of the type; it is not an object. The
+nominal subtype of this value is given by the subtype
+itself (the first subtype in the case of a @fa<type_declaration>), prior to 
+applying any predicate specified directly on the type or subtype. If the type
+or subtype is by-reference, the associated object of the value is the
+object associated (see 6.2) with the evaluation of the usage name.>
+
+@dby
+@xindent<Within an @fa<aspect_specification> for a type or subtype, the
+current instance represents a value of the type; it is not an object. Unless
+otherwise specified, the nominal subtype of this value is given by the subtype
+itself (the first subtype in the case of a @fa<type_declaration>), prior to 
+applying any predicate specified directly on the type or subtype. If the type
+or subtype is by-reference, the associated object of the value is the
+object associated (see 6.2) with the evaluation of the usage name.>
+
+!corrigendum 13.1(13.1/3)
+
+@dinsa
+A @fa<type_declaration> is illegal if it has one or more progenitors, and a
+nonconfirming value was specified for a representation aspect of an ancestor,
+and this conflicts with the representation of some other ancestor. The cases
+that cause conflicts are implementation defined. 
+@dinst
+When specifying an aspect that denotes a subprogram, the profile of the 
+subprogram shall be mode conformant with the one required for the aspect,
+and the convention shall be Ada. Additional requirements are defined for
+particular aspects. 
+
+!corrigendum 13.1.1(21/3)
+
+@drepl
+@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>
+@dby
+@xbullet<an @fa<expression> (other than an @fa<aggregate>), 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;>
+
+!corrigendum 13.1.1(22/3)
+
+@drepl
+@xbullet<an @fa<identifier> specific to the aspect.>
+@dby
+@xbullet<an @fa<identifier> specific to the aspect; or>
+@xbullet<an @fa<aggregate>, which is positional or named, and is composed
+of elements of any of these four kinds of constructs.>
+
+!corrigendum 13.3(6)
+
+@ddel
+For an @fa<attribute_definition_clause> that specifies an attribute that 
+denotes a subprogram, the profile shall be mode conformant with the one 
+required for the attribute, and the convention shall be Ada. Additional 
+requirements are defined for particular attributes. 
+
+!corrigendum 13.13.2(51/3)
+
+@drepl
+For an @fa<attribute_definition_clause> specifying one of these attributes,
+the subtype of the @i<Item> parameter shall be the first subtype or the base 
+subtype if scalar, and the first subtype if not scalar. The same rule applies 
+to the result of the Input function.
+@dby
+For an @fa<attribute_definition_clause> or @fa<aspect_specification> 
+specifying one of these attributes, the subtype of the @i<Item> parameter 
+shall be the first subtype or the base subtype if scalar, and the first
+subtype if not scalar. The same rule applies to the result of the Input
+function.
+
 !ASIS
 
 No ASIS effect.
@@ -85,5 +339,114 @@
 explicitly mentioned in the RM.
 
 ****************************************************************
+
+From the WG 9 review, issue #151.
+
+8.5(5): This note says that an object of an anonymous access type cannot be 
+renamed. However, it seems to me that the second alternative in RM 8.5.1 (1/5),
+the "access_definition" case, does allow such a renaming. Similarly, RM 8.5 (5)
+says that a single task or protected object cannot be renamed since the 
+corresponding type is anonymous, but as we can now omit the subtype_mark from
+the object_renaming_declaration, it seems that such entities can be renamed. 
+Either I am wrong, or the statements in RM 8.5 (5) are wrong.
+
+Tucker Taft replied:
+
+Another good catch! I would suggest we change the note to say:
+
+    10 A task or protected object that is declared by an explicit 
+    object_declaration can be renamed as an object. However, a single task
+    or protected object [cannot]{can} be renamed {only using the form of 
+    renaming that omits specifying the subtype} [since the corresponding type
+    is anonymous (meaning it has no nameable subtypes). For similar reasons, 
+    an object of an anonymous array or access type cannot be renamed].
+
+This is a bit informal (i.e. "specifying the subtype" is not a defined 
+technical notion) but that is generally fine for a "Note".
+
+Your editor replied:
+
+I wonder if this note retains enough value to bother with it at all. The 
+original purpose was to say that not all objects can be renamed, but that is
+False with Ada 202x, and indeed one now can rename most values as well. Saying
+that something can only be renamed with the most simple (and likely common) 
+form of renaming is hardly interesting. We don't need notes to tell people 
+random facts about the language.
+
+I'll write up deleting the note in AI12-0427-1 (the fixup AI), and we can 
+decide if that is acceptable or not in the ARG.
+
+****************************************************************
+
+From the WG 9 review, issue #152.
+
+The nominal (sub)type specified in 8.6(17.1/5) for the "current instance"
+value seems to be overridden in RM 7.3.2 (5/4) for the aspect
+Type_Invariant'Class, and in RM 7.3.3 (4/5) for the aspect 
+Default_Initial_Condition, where different types ("NT") are specified for 
+the current instance. Perhaps this apparent contradiction should be addressed
+in some way, by a note or by an exception phrase in the general rule.
+
+Tucker Taft replied:
+
+Might want to add simply "Unless otherwise specified in this document, ...".
+
+****************************************************************
+
+From the WG 9 review, issue #8.
+
+In RM 13.1.1(19/3-22/3) we have:
+
+Depending on which aspect is identified by the aspect_mark, an
+aspect_definition specifies:
+
+  * a name that denotes a subprogram, object, or other kind of entity;
+  * an 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
+  * an identifier specific to the aspect.
+
+This is relatively old wording, and doesn't mention "aggregate" which is of
+course a kind of expression, but in newer wording is called out separately,
+and it is certainly misleading to talk about it being evaluated to produce a
+"single value."
+
+Suggested fix:
+
+We should augment the above as follows:
+
+Depending on which aspect is identified by the aspect_mark, an
+aspect_definition specifies:
+
+  * a name that denotes a subprogram, object, or other kind of entity;
+  * an expression{ (other than an aggregate)}, 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]
+  * an identifier specific to the aspect{; or
+  * an aggregate, which is positional or named, and is composed of elements of
+    any of these four kinds of constructs}.
+
+****************************************************************
+
+From the WG 9 review, issue #3.
+
+The listed paragraphs give requirements on subprograms specified for
+attributes (aspects) via an attribute_definition_clause. There is no rule
+that does that for aspects specified via aspect_specifications.
+
+There is a usual equivalence of aspects that can be specified via
+aspect_specifications, and the Dewar rule applies here -- it would be highly
+unusual for these rules to act differently than many others.
+
+However, we have been trying to eliminate semantic rules that specifically
+mention how some aspect/attribute is specified, since those can be misread
+easily and are always confusing. So we believe these paragraphs should be
+rewritten.
+
+Note that if we do that for 13.3(6), it should be moved somewhere more
+general (probably 13.1) as it currently is part of rules that only apply to
+attribute_definition_clauses. (A reason this change should be made, IMHO -
+RLB) Even language lawyers (for example, Steve Baird) have had difficulty
+locating this rule when wondering what rules apply to a particular aspect.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent