Version 1.2 of ai12s/ai12-0427-1.txt

Unformatted version of ai12s/ai12-0427-1.txt version 1.2
Other versions for file ai12s/ai12-0427-1.txt

!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
!status received 21-05-07
!priority Low
!difficulty Easy
!subject Fixups from WG 9 review
!summary
(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 associated subprograms with 13.13.2(51/3). We don't have any similar rule for Put_Image in 4.10. The definition of Put_Image seems to suggest that the parameter is of type T, but type do not have names in Ada -- one always has to specify a subtype.
Additionally, the RM we doesn't mention that the implicit calls of Put_Image 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):
For an aspect_specification or attribute_definition_clause specifying Put_Image, the subtype of the Arg parameter shall be the first subtype or the base subtype if scalar, and the first subtype if not scalar.
[Editor's note: This is really a Legality Rule, but we don't currently have such a section here. If we added one, the rule would be far away from the place where it makes sense. Note that stream-oriented attributes don't have Legality Rules section either.]
Add to the end of each of 4.10(28.2/5), 4.10(31/5), 4.10(34/5):
Redundant[Any exception propagated by the call of S'Put_Image is propagated.]
[Editor's note: There is no attempt to have such wording for the default implementations of the stream-oriented attributes, so we make no 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) 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)
Insert new clause:
See the conflict file for the changes.
!corrigendum 8.5(5)
Delete the paragraph:
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 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)
Replace the paragraph:
Within an 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 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.
by:
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 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.
!corrigendum 13.1(13.1/3)
Insert after the paragraph:
A 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.
the new paragraph:
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)
Replace the paragraph:
by:
!corrigendum 13.1.1(22/3)
Replace the paragraph:
by:
!corrigendum 13.3(6)
Delete the paragraph:
For an 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)
Replace the paragraph:
For an attribute_definition_clause 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.
by:
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.
!ASIS
No ASIS effect.
!ACATS test
No ACATS Tests needed.
!appendix

From the WG 9 review, issue #2.

Stream attributes define the subtype of the parameter of the associated
subprograms with 13.13.2(51/3). We don't have any similar rule for Put_Image
in 4.10. The definition of Put_Image seems to suggest that the parameter is
of type T, but types do not have names in Ada -- one always has to specify a
subtype.

Tucker also notes that we don't mention that the implicit calls of Put_Image
propagate any exceptions (including those caused by a subtype check
failure); we doubt anyone would expect anything else, but it usually is
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