Version 1.8 of ai12s/ai12-0159-1.txt

Unformatted version of ai12s/ai12-0159-1.txt version 1.8
Other versions for file ai12s/ai12-0159-1.txt

!standard 3.5.9(6)          15-03-31 AI12-0159-1/04
!standard 4.1.4(9/4)
!standard 6.1.1(7/4)
!standard 6.1.1(26.2/4)
!standard 6.1.1(37/4)
!standard 6.1.1(38/4)
!standard 6.3.1(12/4)
!standard 6.3.1(13/4)
!standard 6.4.1(5)
!standard 6.4.1(6.26/4)
!standard 6.4.1(6.27/4)
!standard 6.4.1(6.28/4)
!standard 6.4.1(6.29/4)
!standard 6.4.1(13.1/4)
!standard 7.3.2(5/4)
!standard 7.3.2(21/4)
!standard 7.3.2(22.1/4)
!standard 11.3(3/4)
!standard 11.3(3.2/4)
!standard 11.3(4.1/4)
!standard A(3.1/4)
!standard A.18.10(2/4)
!class binding interpretation 15-03-23
!status Corrigendum 1-2012 15-03-26
!status WG9 Approved 15-06-26
!status ARG Approved 8-0-2 15-03-26
!status work item 15-03-23
!status received 15-02-26
!priority Low
!difficulty Easy
!qualifier Omission
!subject Corrections from the Corrigendum Editorial Review
!summary
Various issues with normative wording found during editorial reviews are addressed.
!question
(1) There does not appear to be any resolution rule that applies to a digits_constraint. Should there be one? (Yes.)
(2) In 6.1.1(38/4) and 7.3.2(22.1/4), are the commas in the right place? (No.)
(3) There is a missing "the" in 7.3.2(21/4). Should it be added? (Yes.)
(4) In A.18.10(2/4), "consists of" would be better than "comprises of". The comma after root node seems misplaced. Should these be changed? (Yes.)
(5) In A(3.1/4), we have both "input-output" and "input/output". One of them must be wrong, right? (Yes.)
(6) In 11.3(4.1/4), "rather than" sounds odd. Wouldn't "instead of" be better?
(7) In 11.3(3/4), the original "if any" text makes more sense. Should it be replaced? (Yes.)
(8) The type of a raise_expression is too vague. We don't want it to match anything in any circumstance, else it becomes impossible to enforce Legality Rules that depend on the type of an expression. (For instance, in an extension aggregate ((raise Something) with ...), does (raise Something) have a specific tagged type?) Should this be fixed? (Yes.)
(9) The last two sentences of 6.1.1(7/4) are non-normative discussion that better belongs in the AARM. Should it be moved there? (Yes.)
(10) In 6.3.1(12/4), the first and third (existing) cases start "for a", but the (new) second case starts just "a". Should a third "for" be added? (Yes.) Similarly 6.3.1(13/4) should include "for", right? (Yes.)
(11) 6.4.1(6.26-6.29/4) look like a continuation of the rules above them 6.4.1(6.18-6.25/3), but they're not. Would these be better placed after 6.4.1(5)? (Yes.)
(12) In 6.4.1(13.1-4/4), the "except in the following case:" is awkward and ambiguous. Can we do better? (Yes.)
(13) 6.4.1(26.2/4) says "is of an anonymous access, ...". Is the word "type" missing here? (Yes.)
(14) 6.1.1(37/4) starts out with
For any subprogram or entry call S (including dispatching calls),
which suggests that S is the call (i.e., an expression or statement), not the callee (i.e., a subprogram). The rest of the paragraph goes on to treat S as though it is the callee.
Contrast this with the correct phrasing in paragraph 38:
The class-wide precondition check for a call to a subprogram or entry S...
Should this be fixed? (Yes.)
(15) 4.1.4(9/4) mentions "without constraint or null exclusion" without mentioning predicates, which presumably are also ignored here. Should they be mentioned? (Yes.)
!recommendation
(See Summary.)
!wording
(1)
Add after 3.5.9(6):
The simple_expression of a digits_constraint is expected to be of any integer type.
(2)
Modify 6.1.1(38/4):
The class-wide precondition check for a call to a subprogram or entry S consists solely of checking the class-wide precondition expressions that apply to the denoted callable entity (not necessarily to the one that is invoked). Any operations within such an expression that were resolved as primitive operations of the (notional) formal derived type NT[,] are in the evaluation of the precondition bound to the corresponding operations of the type identified by the controlling tag of the call on S. This applies to both dispatching and non-dispatching calls on S.
Modify 7.3.2(22.1/4):
For an invariant check on a value of type T1 based on a class-wide invariant expression inherited from an ancestor type T, any operations within the invariant expression that were resolved as primitive operations of the (notional) formal derived type NT[,] are{ bound to the corresponding operations of type T1} in the evaluation of the invariant expression for the check on T1[ bound to the corresponding operations of type T1].
(3)
Modify 7.3.2(21/4):
If performing checks is required by the Type_Invariant or Type_Invariant'Class assertion policies (see 11.4.2) in effect at the point of {the} corresponding aspect specification applicable to a given type, then the respective invariant expression is considered enabled.
(4)
Modify A.18.10(2/4):
A multiway tree container object manages a tree of nodes, {consisting}[comprising] of a root node[,] and a set of internal nodes{;} each {internal node}[of which] contains an element and pointers to the parent, first child, last child, next (successor) sibling, and previous (predecessor) sibling internal nodes. A cursor designates a particular node within a tree (and by extension the element contained in that node, if any). A cursor keeps designating the same node (and element) as long as the node is part of the container, even if the node is moved within the container.
(5)
Modify A(3.1/4):
For the purpose of determining whether concurrent calls on text input-output subprograms are required to perform as specified above, when calling a subprogram within Text_IO or its children that implicitly operates on one of the default input{-}[/]output files, the subprogram is considered to have a parameter of Current_Input or Current_Output (as appropriate).
(6)
Modify 11.3(4.1/4):
If the evaluation of a string_expression or string_simple_expression raises an exception, that exception is propagated {instead of}[rather than] the one denoted by the exception_name of the raise_statement or raise_expression.
(7)
Modify 11.3(3/4):
[An exception_name]{The exception_name, if any,} of a raise_statement or raise_expression ...
(8)
Replace 11.3(3.2/4) by:
The expected type for a raise_expression shall be any single type.
(9)
Modify 6.1.1(7/4):
Within the expression for a Pre'Class or Post'Class aspect for a primitive subprogram S of a tagged type T, a name that denotes a formal parameter (or S'Result) of type T is interpreted as though it had a (notional) type NT that is a formal derived type whose ancestor type is T, with directly visible primitive operations. Similarly, a name that denotes a formal access parameter (or S'Result) of type access-to-T is interpreted as having type access-to-NT. The result of this interpretation is that the only operations that can be applied to such names are those defined for such a formal derived type. [This ensures that the expression is well-defined for any primitive subprogram of a type descended from T.]
Add an AARM note:
Reason: This ensures that the expression is well-defined for any primitive subprogram of a type descended from T.
Modify 7.3.2(5/4):
Within an invariant expression, the identifier of the first subtype of the associated type denotes the current instance of the type. Within an invariant expression for the Type_Invariant aspect of a type T, the type of this the current instance is T. Within an invariant expression for the Type_Invariant'Class aspect of a type T, the type of this current instance is interpreted as though it had a (notional) type NT that is a visible formal derived type whose ancestor type is T. The effect of this interpretation is that the only operations that can be applied to this current instance are those defined for such a formal derived type.[ This ensures that the invariant expression is well-defined for any type descended from T.]. Add an AARM note:
Reason: The rules for Type_Invariant'Class ensure that the invariant expression is well-defined for any type descended from T.
(10)
Modify 6.3.1(12/4):
* The default calling convention is *protected* for a protected
subprogram, {for} a prefixed view of a subprogram with a synchronization kind of By_Protected_Procedure, and for an access-to-subprogram type with the reserved word protected in its definition.
Modify 6.3.1(13/4): * The default calling convention is *entry*
for an entry and {for} a prefixed view of a subprogram with a synchronization kind of By_Entry.
(11)
Move 6.4.1(6.26-6.29/4) after 6.4.1(5).
(12)
Modify 6.4.1(13.1/4):
* For a scalar type that has the Default_Value aspect specified, the
formal parameter is initialized from the value of the actual, without checking that the value satisfies any constraint or any predicate{. Furthermore, }[, except in the following case:] if the actual parameter is a view conversion and either
(13)
Modify 6.1.1(26.2/4):
* If X is of an anonymous access {type} defined by an access_definition A then
(14)
Modify 6.1.1(37/4):
For any {call to a} subprogram or entry [call] S (including dispatching calls), the checks that are performed to verify specific precondition expressions and specific and class-wide postcondition expressions are determined by those for the subprogram or entry actually invoked. Note that the class-wide postcondition expressions verified by the postcondition check that is part of a call on a primitive subprogram of type T includes all class-wide postcondition expressions originating in any progenitor of T, even if the primitive subprogram called is inherited from a type T1 and some of the postcondition expressions do not apply to the corresponding primitive subprogram of T1. Any operations within a class-wide postcondition expression that were resolved as primitive operations of the (notional) formal derived type NT, are in the evaluation of the postcondition bound to the corresponding operations of the type identified by the controlling tag of the call on S. This applies to both dispatching and non-dispatching calls on S.
(15)
Modify 4.1.4(9/4):
An attribute_reference denotes a value, an object, a subprogram, or some other kind of program entity. Unless explicitly specified otherwise, for an attribute_reference that denotes a value or an object, if its type is scalar, then its nominal subtype is the base subtype of the type; if its type is tagged, its nominal subtype is the first subtype of the type; otherwise, its nominal subtype is a subtype of the type without any constraint{,}[ or] null_exclusion{, or predicate}. Similarly, unless explicitly specified otherwise, for an attribute_reference that denotes a function, when its result type is scalar, its result subtype is the base subtype of the type, when its result type is tagged, the result subtype is the first subtype of the type, and when the result type is some other type, the result subtype is a subtype of the type without any constraint{,}[ or] null_exclusion{, or predicate}.
!discussion
(1) This appears to be an oversight.
(2) Comma madness. :-)
(3) Helps to edit. ;-) This is in part of the paragraph introduced by a last-minute change in the Ada 2012 wording.
(4) "comprising of" is just weird. The comma after "root node" is also weird, but it is very important to the meaning (as the contents of the "root node" are defined in the next paragraph, it's not the list following "internal node"). Thus we break the sentence into two parts so that we no longer need the comma, by repeating the part about the internal nodes.
(5) The standard usually uses "input-output" to describe files, libraries, etc., not "input/output".
(6) The RM/AARM uses "rather than" more often than "instead of". (175 occurrences to 55) Still, "instead of" sounds better to the Editor's ear as well as the commenter. The commenter suggests that "rather than" best applies to a substitute action, and "instead of" best applies to a substitute object. For example: He kicked rather than hit the ball. He hit the ball instead of the balloon. And this sentence is talking about replacing the object (an exception) rather than replacing the action (propagation).
(7) The wording was changed from the original "if any" wording (which is now the new wording), to the "An" wording, during discussion during the Stockholm ARG meeting. The objection appears to have been that the exception_name is not optional for a raise_expression, so "if any" is weird. However, the "An" wording seems to imply that there can be more than one, so it isn't clearly better.
(8) The suggested wording is similar to the way aggregates and string literals work, other entities that themselves do not provide a type.
This is incompatible in weird cases. For instance, this bans raise expressions from being the operand of a type conversion (a qualified expression should be used instead). This appears to include the case where a type conversion is distributed to the operands of a conditional expression: T(if A then B else raise Constraint_Error) is illegal by this rule.
(9) The last sentence of 6.1.1(7/4) comes unmodified from Ada 2012 text.
We considered adding a user note, but of course that is not near the rules in question. Thus it would come too late to really be helpful in explaining the changes.
(10) These are unintended inconsistencies in wording. Most of the 6.3.1 bullets are written in the form of "the calling convention for <something> is <some-convention>".
(11) These rules do get lost after the anti-aliasing rules, they should have more visibility.
The best place to move these rules would be after 6.4.1(6.4/3), since that is the last rule other than the anti-aliasing rules. But inserting them there would change all of the paragraph numbers following (we don't allow inserts of inserts for paragraph numbers). We don't want to do that.
So, after 6.4.1(5) is the only sensible alternative for the placement of these rules.
(12) Since this additional text specifies an additional, non-optional check, it doesn't really matter to which it applies, other than the part about "for a scalar type with Default_Value specified". Whether a parameter that fails this check is initialized cannot be determined (the parameter could not be read), and initialization cannot raise an exception. Thus separating it as suggested (or even making it a separate paragraph under the same bullet) is OK.
(13) "anonymous access" by itself doesn't mean anything, it needs to modify something. In this case, that's a type. Arguably, that can be inferred from the fact that an access_definition (which declares an anonymous type) is involved, but it's better to be explicit.
(14) The questioner is correct about the change in meaning of S. The wording should be fixed.
(15) We certainly don't mean to include predicates in this case, so we need to explicit mention that they don't apply (two places). This is clearly an omission.
!corrigendum 3.5.9(6)
Insert after the paragraph:
For a type defined by a fixed_point_definition, the delta of the type is specified by the value of the expression given after the reserved word delta; this expression is expected to be of any real type. For a type defined by a decimal_fixed_point_definition (a decimal fixed point type), the number of significant decimal digits for its first subtype (the digits of the first subtype) is specified by the expression given after the reserved word digits; this expression is expected to be of any integer type.
the new paragraph:
The simple_expression of a digits_constraint is expected to be of any integer type.
!corrigendum 4.1.4(9/4)
Replace the paragraph:
An attribute_reference denotes a value, an object, a subprogram, or some other kind of program entity. For an attribute_reference that denotes a value or an object, if its type is scalar, then its nominal subtype is the base subtype of the type; if its type is tagged, its nominal subtype is the first subtype of the type; otherwise, its nominal subtype is a subtype of the type without any constraint or null_exclusion. Similarly, unless explicitly specified otherwise, for an attribute_reference that denotes a function, when its result type is scalar, its result subtype is the base subtype of the type, when its result type is tagged, the result subtype is the first subtype of the type, and when the result type is some other type, the result subtype is a subtype of the type without any constraint or null_exclusion.
by:
An attribute_reference denotes a value, an object, a subprogram, or some other kind of program entity. Unless explicitly specified otherwise, for an attribute_reference that denotes a value or an object, if its type is scalar, then its nominal subtype is the base subtype of the type; if its type is tagged, its nominal subtype is the first subtype of the type; otherwise, its nominal subtype is a subtype of the type without any constraint, null_exclusion, or predicate. Similarly, unless explicitly specified otherwise, for an attribute_reference that denotes a function, when its result type is scalar, its result subtype is the base subtype of the type, when its result type is tagged, the result subtype is the first subtype of the type, and when the result type is some other type, the result subtype is a subtype of the type without any constraint, null_exclusion, or predicate.
!corrigendum 6.1.1(7/3)
Replace the paragraph:
Within the expression for a Pre'Class or Post'Class aspect for a primitive subprogram of a tagged type T, a name that denotes a formal parameter of type T is interpreted as having type T'Class. Similarly, a name that denotes a formal access parameter of type access-to-T is interpreted as having type access-to-T'Class. This ensures that the expression is well-defined for a primitive subprogram of a type descended from T.
by:
Within the expression for a Pre'Class or Post'Class aspect for a primitive subprogram S of a tagged type T, a name that denotes a formal parameter (or S'Result) of type T is interpreted as though it had a (notional) type NT that is a formal derived type whose ancestor type is T, with directly visible primitive operations. Similarly, a name that denotes a formal access parameter (or S'Result) of type access-to-T is interpreted as having type access-to-NT. The result of this interpretation is that the only operations that can be applied to such names are those defined for such a formal derived type.
!corrigendum 6.1.1(26/3)
Replace the paragraph:
X'Old
For each X'Old in a postcondition expression that is enabled, a constant is implicitly declared at the beginning of the subprogram or entry. The constant is of the type of X and is initialized to the result of evaluating X (as an expression) at the point of the constant declaration. The value of X'Old in the postcondition expression is the value of this constant; the type of X'Old is the type of X. These implicit constant declarations occur in an arbitrary order.
by:
X'Old
Each X'Old in a postcondition expression that is enabled denotes a constant that is implicitly declared at the beginning of the subprogram body, entry body, or accept statement.
The implicitly declared entity denoted by each occurrence of X'Old is declared as follows:
The nominal subtype of X'Old is as implied by the above definitions. The expected type of the prefix of an Old attribute is that of the attribute. Similarly, if an Old attribute shall resolve to be of some type, then the prefix of the attribute shall resolve to be of that type.
!corrigendum 6.1.1(37/3)
Replace the paragraph:
For any subprogram or entry call (including dispatching calls), the checks that are performed to verify specific precondition expressions and specific and class-wide postcondition expressions are determined by those for the subprogram or entry actually invoked. Note that the class-wide postcondition expressions verified by the postcondition check that is part of a call on a primitive subprogram of type T includes all class-wide postcondition expressions originating in any progenitor of T, even if the primitive subprogram called is inherited from a type T1 and some of the postcondition expressions do not apply to the corresponding primitive subprogram of T1.
by:
For any call to a subprogram or entry S (including dispatching calls), the checks that are performed to verify specific precondition expressions and specific and class-wide postcondition expressions are determined by those for the subprogram or entry actually invoked. Note that the class-wide postcondition expressions verified by the postcondition check that is part of a call on a primitive subprogram of type T includes all class-wide postcondition expressions originating in any progenitor of T, even if the primitive subprogram called is inherited from a type T1 and some of the postcondition expressions do not apply to the corresponding primitive subprogram of T1. Any operations within a class-wide postcondition expression that were resolved as primitive operations of the (notional) formal derived type NT, are in the evaluation of the postcondition bound to the corresponding operations of the type identified by the controlling tag of the call on S. This applies to both dispatching and non-dispatching calls on S.
!corrigendum 6.1.1(38/3)
Replace the paragraph:
The class-wide precondition check for a call to a subprogram or entry consists solely of checking the class-wide precondition expressions that apply to the denoted callable entity (not necessarily the one that is invoked).
by:
The class-wide precondition check for a call to a subprogram or entry S consists solely of checking the class-wide precondition expressions that apply to the denoted callable entity (not necessarily to the one that is invoked). Any operations within such an expression that were resolved as primitive operations of the (notional) formal derived type NT are in the evaluation of the precondition bound to the corresponding operations of the type identified by the controlling tag of the call on S. This applies to both dispatching and non-dispatching calls on S.
!corrigendum 6.3.1(12)
Replace the paragraph:
by:
!corrigendum 6.3.1(13)
Replace the paragraph:
by:
!comment 6.4.1(6.26-9/4) moves to 6.4.1(5) - This change is
!comment made in the !corrigendum of the original AI (AI12-0074-1).
!corrigendum 6.4.1(13.1/3)
Replace the paragraph:
by:
then Program_Error is raised;
!corrigendum 7.3.2(5/3)
Replace the paragraph:
Within an invariant expression, the identifier of the first subtype of the associated type denotes the current instance of the type. Within an invariant expression associated with type T, the type of the current instance is T for the Type_Invariant aspect and T'Class for the Type_Invariant'Class aspect.
by:
Within an invariant expression, the identifier of the first subtype of the associated type denotes the current instance of the type. Within an invariant expression for the Type_Invariant aspect of a type T, the type of this current instance is T. Within an invariant expression for the Type_Invariant'Class aspect of a type T, the type of this current instance is interpreted as though it had a (notional) type NT that is a visible formal derived type whose ancestor type is T. The effect of this interpretation is that the only operations that can be applied to this current instance are those defined for such a formal derived type.
!corrigendum 7.3.2(21/3)
Replace the paragraph:
If performing checks is required by the Invariant or Invariant'Class assertion policies (see 11.4.2) in effect at the point of corresponding aspect specification applicable to a given type, then the respective invariant expression is considered enabled.
by:
If performing checks is required by the Type_Invariant or Type_Invariant'Class assertion policies (see 11.4.2) in effect at the point of the corresponding aspect specification applicable to a given type, then the respective invariant expression is considered enabled.
!corrigendum 7.3.2(22/3)
Insert after the paragraph:
The invariant check consists of the evaluation of each enabled invariant expression that applies to T, on each of the objects specified above. If any of these evaluate to False, Assertions.Assertion_Error is raised at the point of the object initialization, conversion, or call. If a given call requires more than one evaluation of an invariant expression, either for multiple objects of a single type or for multiple types with invariants, the evaluations are performed in an arbitrary order, and if one of them evaluates to False, it is not specified whether the others are evaluated. Any invariant check is performed prior to copying back any by-copy in out or out parameters. Invariant checks, any postcondition check, and any constraint or predicate checks associated with in out or out parameters are performed in an arbitrary order.
the new paragraph:
For an invariant check on a value of type T1 based on a class-wide invariant expression inherited from an ancestor type T, any operations within the invariant expression that were resolved as primitive operations of the (notional) formal derived type NT are bound to the corresponding operations of type T1 in the evaluation of the invariant expression for the check on T1.
!corrigendum 11.3(3)
Replace the paragraph:
The name, if any, in a raise_statement shall denote an exception. A raise_statement with no exception_name (that is, a re-raise statement) shall be within a handler, but not within a body enclosed by that handler.
by:
The exception_name, if any, of a raise_statement or raise_expression shall denote an exception. A raise_statement with no exception_name (that is, a re-raise statement) shall be within a handler, but not within a body enclosed by that handler.
!corrigendum 11.3(3.1/2)
Replace the paragraph:
The expression, if any, in a raise_statement, is expected to be of type String.
by:
A string_expression of a raise_statement or raise_expression is expected to be of type String.
The expected type for a raise_expression shall be any single type.
!corrigendum 11.3(4/2)
Replace the paragraph:
To raise an exception is to raise a new occurrence of that exception, as explained in 11.4. For the execution of a raise_statement with an exception_name, the named exception is raised. If a string_expression is present, the expression is evaluated and its value is associated with the exception occurrence. For the execution of a re-raise statement, the exception occurrence that caused transfer of control to the innermost enclosing handler is raised again.
by:
To raise an exception is to raise a new occurrence of that exception, as explained in 11.4. For the execution of a raise_statement with an exception_name, the named exception is raised. Similarly, for the evaluation of a raise_expression, the named exception is raised. In both of these cases, if a string_expression or string_simple_expression is present, the expression is evaluated and its value is associated with the exception occurrence. For the execution of a re-raise statement, the exception occurrence that caused transfer of control to the innermost enclosing handler is raised again.
NOTES
1 If the evaluation of a string_expression or string_simple_expression raises an exception, that exception is propagated instead of the one denoted by the exception_name of the raise_statement or raise_expression.
!corrigendum A(3)
Replace the paragraph:
The implementation shall ensure that each language-defined subprogram is reentrant in the sense that concurrent calls on the same subprogram perform as specified, so long as all parameters that could be passed by reference denote nonoverlapping objects.
by:
The implementation shall ensure that each language-defined subprogram is reentrant in the sense that concurrent calls on any language-defined subprogram perform as specified, so long as all objects that are denoted by parameters that could be passed by reference or designated by parameters of an access type are nonoverlapping.
For the purpose of determining whether concurrent calls on text input-output subprograms are required to perform as specified above, when calling a subprogram within Text_IO or its children that implicitly operates on one of the default input-output files, the subprogram is considered to have a parameter of Current_Input or Current_Output (as appropriate).
!corrigendum A.18.10(2/3)
Replace the paragraph:
A multiway tree container object manages a tree of internal nodes, each of which contains an element and pointers to the parent, first child, last child, next (successor) sibling, and previous (predecessor) sibling internal nodes. A cursor designates a particular node within a tree (and by extension the element contained in that node, if any). A cursor keeps designating the same node (and element) as long as the node is part of the container, even if the node is moved within the container.
by:
A multiway tree container object manages a tree of nodes, consisting of a root node and a set of internal nodes; each internal node contains an element and pointers to the parent, first child, last child, next (successor) sibling, and previous (predecessor) sibling internal nodes. A cursor designates a particular node within a tree (and by extension the element contained in that node, if any). A cursor keeps designating the same node (and element) as long as the node is part of the container, even if the node is moved within the container.
!ASIS
No ASIS effect.
!ACATS test
!appendix

From: Randy Brukardt
Sent: Thursday, February 26, 2015  11:15 PM

I was wondering why I didn't need to fix up a resolution rule for
digits_constraint. That turns out to be easy: there isn't any rule to fix up!

3.5.9 has resolution rules for Decimal_Fixed_Point_Definition and
Ordinary_Fixed_Point_Definition, and requires staticness of all of these
(including digits_constraint). But no resolution rule for the expression of the
digits_constraint.

This must be highly important, because its been true since the initial version
of Ada 95. :-)

One can sort of infer a resolution rule from 3.5.9(6) and from 3.5.7(4)
[depending upon whether it is a float or decimal constraint], and of course
there's Ada 83 (which treats types and subtypes the same). But it sure seems odd
that we have a complete definition of delta_constraint in J.3, including
resolution, and definitions of the resolution of all of the kinds of type
definitions, yet we never mention resolution of digits_constraint in 3.5.9 or
anywhere else.

Adding "The simple_expression of a digits_constraint is expected to be of any
integer type." to 3.5.9(6) would seem to be indicated.

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

From: Bob Duff
Sent: Friday, February 27, 2015  9:46 AM

> This must be highly important, because its been true since the initial
> version of Ada 95. :-)

Yeah, well for me this one falls into the category "waste of time".
We all have better things to do than polishing the RM for years on end.

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

From: Randy Brukardt
Sent: Friday, February 27, 2015  3:52 PM

We could put it into the AI of "things we don't intend to fix".

The AI of "things we don't intend to fix" contains cases where wording seems
messy, and thus there is a significant chance of introducing bugs. I don't see
how that applies here: "The simple_expression of a digits_constraint is expected
to be of any integer type." is completely straighforward.

I agree we shouldn't go looking for such things, but it's hard to justify
ignoring them when found, especially when the amount of work is essentially the
same either way. (I'd have to write up the issue and explain why we don't want
to fix it; it'd be a lot easier to just do so.) In most such cases, we're
talking about something muddled, as opposed to outright missing, which is not as
clear-cut; it's likely to be more dangerous to change.

The only question in my mind is whether 3.5.7(4) could be read to make the
needed definition. The sentence doesn't mention what syntax it applies to, so
one could argue that it is intended to apply to any expression that immediately
follows "digits" in the syntax. But I don't buy that; the syntax in question
isn't in this clause (which implies a long-distance effect that we typically
avoid), and the value after digits is never referred to as "requested decimal
precision" in 3.5.9 (where the syntax actually is), 3.5.9 specifically defines
the resolution of the value after digits for a decimal_fixed_point_definition
(which seems to put the lie to the idea that this was intended to apply to all
expressions that follow "digits"), and indeed, the constraint doesn't even have
to be used on a floating point value (so it seems odd to be using float-specific
terminology with it).

I've now probably spent 4 times as much time on this as it would have taken to
just write up a trivial AI to insert the line. Demonstrates that not only are
some things too simple that they're a waste of time to fix, but that's it's
possible for them to be so simple that it's a waste of time to complain about
them being a waste of time. :-)

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

From: Robert Dewar
Sent: Friday, February 27, 2015  4:00 PM

> I agree we shouldn't go looking for such things, but it's hard to
> justify ignoring them when found, especially when the amount of work
> is essentially the same either way.

We could have the good taste just to ignore trivial matters without wasting time
on them :-)

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

From: Bob Duff
Sent: Friday, February 27, 2015  4:20 PM

> I've now probably spent 4 times as much time on this as it would have
> taken to just write up a trivial AI to insert the line. Demonstrates
> that not only are some things too simple that they're a waste of time
> to fix, but that's it's possible for them to be so simple that it's a
> waste of time to complain about them being a waste of time. :-)

I suggest you don't bring such issues up in the first place.  Then nobody will
waste time.

Save it for cases where some compiler writer is genuinely confused, or where
compilers disagree, and other useful cases.

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

From: Randy Brukardt
Sent: Friday, February 27, 2015  5:53 PM

So you want me to ignore anything I find in RM when working on the ACATS or when
editing, because there's a 0% chance of me knowing anything about the above in
those cases? (I'm neither acting as a compiler writer nor running multiple
compilers in those roles [discounting Janus/Ada for this purpose, since it's
rare that it provides useful information on the margins].) I can only find
problems where the intent as I understand it doesn't match the actual wording,
or as in this case, where there appears to be no wording at all. Trying to guess
whether a bug is going to be "significant" to someone is not really practical.

In general, people report far too few "trivial" things, meaning that they never
get fixed. That's not even solely a software problem, you see that in retail and
government and lots of other things as well. No one can fix things that they
don't know about!

Thus, I think pretty much everything should be *reported*, and leave it to our
"triage" system to decide what is important enough to put on the ARG agenda.

In this particular case, the bug is relatively horrible, in that the *type* of
an entire Ada construct is never defined. That's of course mitigated by the fact
that one can infer that it's supposed to work like other similar features, and
of course by the fact that the specific feature is hardly ever used. It's these
latter facts that give it a low priority, not the nature of the bug.

Given that in this case the bug can be fixed by adding a single sentence, the
sentence is similar to existing sentences, the sentence is specific to the
feature in question so it can't cause any conflicts, and because fixing these
things isn't done in a vacuum, but rather bundled with lots of other fixes (i.e.
a Corrigendum) so the incremental cost is low, I sent it as a stand-alone report
with the intent of writing a quickie AI to apply the fix.

If the fix would have been more complex, I still would have sent a report, but
would have suggested putting it into the "things we don't intend to fix" AI or
just filing it into an AC. But never reporting problems means that future
maintainers don't have the opportunity to fix things that we didn't, because no
one can fix anything they don't know about. (That would be especially important
should the standard get a complete overhaul, something I hope never happens. But
I don't want to make it harder for future maintainers, either.)

I don't want to be the sole arbiter of whether something needs fixing, and I
surely don't want any other single individual making that call, either. And
griping about what happens to be discovered really doesn't help, either.

If you would like to propose some alternative process for dealing with reports
like this one that does not involve sweeping them under the rug, please go
ahead. It would be useful to have some lightweight way to deal with stuff of
this sort (that's more than presentation, but obvious as to the fix). But I'm
not at all on board with ignoring genuine bugs in the Standard (or anything, for
that matter); there's a vast difference between "low priority" and "no
priority".

P.S. Now I'm up to 7 times as much time because I have to defend fixing actual
bugs in the Standard. Grumble.

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

From: Robert Dewar
Sent: Saturday, February 28, 2015  6:22 AM

And you are wasting time because this defense is misguided IMO

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

From: Robert Dewar
Sent: Saturday, February 28, 2015  6:24 AM

Here's the deal Randy, the RM is full of errors about things that don't matter.
Fixing one of them has no practical impact whatsoever. If you notice some small
error where the intent is obvious and there is no real problem, you should
ignore it.

It would be nice to have a goal of a 100% error free RM, but that's
unobtainable, so any action that has as part of its rationale achieving this is
flawed, at least with respect to this rationale.

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

From: Robert Dewar
Sent: Saturday, February 28, 2015  6:26 AM

One way of handling absolutely trivial matters such as this where the fix is (a)
unimportant to anyone and (b) trivial, is to just do the fix, the same way you
would fix a spelling error.

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

From: Randy Brukardt
Sent: Saturday, February 28, 2015  7:07 PM

Sigh. That's what I intended to do, of course. A spelling error in ancient text
(not new text) would go into a presentation AI with lots of similar fixes and
eventually the ARG votes on it when we're going to produce a document or it is
getting unwieldy (usually only takes a couple of minutes). I've done the same
with "trivial" fixes as well, although it happens that what I think is trivial
doesn't always turn out to be universal.

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

From: Jeff Cousins
Sent: Monday, March 2, 2015  5:49 AM

> I don't want to be the sole arbiter of whether something needs fixing, and I
> surely don't want any other single individual making that call, either.

I think Randy was correct to raise this, for the reason he gave, though quietly
writing up a trivial AI to insert the line might have avoided another long
e-mail chain.  (Please don't continue it!)

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

From: Tucker Taft
Sent: Monday, March  9, 2015  3:21 PM

Here are my comments.  I reviewed the text in the AARM PDF.
...
[Editor's note: Only normative comments that caused items in this AI are
recorded here. That goes for much of the following mail through March 25, 2015.]

11.2(3/4) "[An exception_name]{The exception_name, if any} of a raise_statement
or raise_expression ..." (AI12-0022-1)

11.2(3.1/4) "[A string_expression]{The string_expression or 
string_simple_expression, if any} of a raise_statement or raise_expression,
..." (AI12-0022-1)

11.2(3.2/4) "A raise_expression is expected to be of any type." doesn't make 
sense to me. I believe this should say:

    "The expected type for a raise_expression shall be any single type."

analogous to the way aggregates and string literals work. (AI12-0022-1)
...

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

From: Steve Baird
Sent: Wednesday, March 11, 2015  2:12 PM

...
Typo (missing word "type") in 6.1.1(26.4/4)

    If X is of an anonymous access [type]
    defined by an access_definition A then

====

6.1.1(37/4) starts out with
    For any subprogram or entry call S (including dispatching calls),

which suggests that S is the call (i.e., an expression or statement), not
the callee (i.e., a subprogram). The rest of the paragraph goes on to treat
S as though it is the callee.

Contrast this with the correct phrasing in paragraph 38:
   The class-wide precondition check for a call to a subprogram
   or entry S

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

From: Steve Baird
Sent: Thursday, March 12, 2015  1:30 PM


I've sent the simple editorial ones to Randy and Jeff in a separate message.

These are the more interesting ones.

====

In 4.1.4 we've got

   Unless explicitly specified otherwise, for an attribute_reference
   that denotes a value or an object, if its type is scalar, then its
   nominal subtype is the base subtype of the type; if its type is
   tagged, its nominal subtype is the first subtype of the type;
   otherwise, its nominal subtype is a subtype of the type without
   any constraint or null_exclusion.

a) I don't think "first subtype" is defined for a generic formal type
    (and this definition occurs in a "static semantics" section).

b) "without any constraint or null_exclusion" doesn't mention
    predicates.

I haven't tried to find a specific attribute where either of these makes a
difference. Randy pointed out (in private communication) that the "first
subtype" issue might be a problem in other (static semantics) contexts
where that term is used.

====

In 4.1.6, we've got a new note
    The Constant_Indexing and Variable_Indexing aspects
    cannot be redefined when inherited for a derived type,
    but the functions that they denote can be modified by overriding
    or overloading.

I'm thinking about the case of a derived type which inherits, say, a
Constant_Indexing aspect. I think the RM wording correctly handles this case
but it is obscure enough that a clarifying note is needed.

The crux of the matter is the name resolution rule

   When a generalized_indexing is interpreted as a constant (or
   variable) indexing, it is equivalent to a call on a prefixed view of
   one of the functions named by the Constant_Indexing (or
   Variable_Indexing) aspect of the type of the
   indexable_container_object_prefix with the given
   actual_parameter_part, and with the indexable_container_object_prefix
   as the prefix of the prefixed view.

and the meaning, in the case of a derived type which inherits the aspect, of
the phrase

   "the functions named by the Constant_Indexing (or
    Variable_Indexing) aspect of the type"
.

We want that phrase to mean the set of subprograms where the equivalent
prefixed call would work as defined in 4.1.3(9.2/3).
And it does mean that - the wording is correct; the name given in the aspect
spec is, roughly speaking, re-resolved in the context of the derived type.

My point is that this is far from obvious. I was quite confused about this
until Randy pointed out to me the significance of the use of the word "named"
instead of "denoted". This is subtle stuff and there is nothing similar to
this kind of re-resolution in other Ada constructs.

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

From: Brad Moore
Sent: Sunday, March 15, 2015  1:36 PM

7.3.2 (10.1/4)

"After successful explicit initialization of the completion of a deferred
constant with a part of type T, if the completion is inside the immediate
scope of the full view of T[,] and the deferred constant is visible outside
the immediate scope of T, the check is performed on the part(s) of type T;"

I'm thinking comma that I've highlighted shouldn't be there. Am I right?

7.3.2 (21/4)
"If performing checks is required by the Type_Invariant or Type_Invariant'Class
assertion policies (see 11.4.2) in effect at the point of {the} corresponding
aspect specification applicable to a given type, then the respective invariant
expression is considered enabled."

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

From: Gary Dismukes
Sent: Monday, March 23, 2015  8:36 PM

7.3.2
-----

Change commas as indicated below, deleting one comma and inserting two:

22.1/4  For an invariant check on a value of type T1 based on a class-wide
        invariant expression inherited from an ancestor type T, any operations
        within the invariant expression that were resolved as primitive
        operations of the (notional) formal derived type NT[,] are{,} in the
        evaluation of the invariant expression for the check on T1{,} bound to
        the corresponding operations of type T1.

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

From: John Barnes
Sent: Saturday, March 14, 2015  9:02 AM

11.2(4.1/4). Tuck suggests changing "rather than" to "instead of".

I am unsure as to whether I prefer "rather than" instead of 
"instead of" or maybe "instead of" rather than "rather than". 
 I think we need a global vote on this linguistic nicety. In 
the first 100 pages of the AARM, rather than occurs 19 times 
whereas instead of occurs only 4 times.

Annex A

A 3.1.4  Sometimes we have input-output and sometimes input/output. A survey of
the RM as a whole shows that input-output dominates and that the casual uses of
input/output are somewhat random. I suggest that in this para we replace
input/output by input-output.

I tried to search for input output (without hyphen or slash) but the wretched
thing found those with hyphen or slash as well.

A.18.10(2/4)  I would have preferred either "comprising" or "consisting of"
rather than (perchance instead of) "comprising of". Fowler agrees with me. I
should have noticed that at editorial review but I was grumbling about a comma
then. But leave it, it's an example of the same sort of  construction as
"inside of ".

A.18.10(3/4)  I could mutter about "all of" rather than plain "all". Fowler
says that including of is fairly modern (from 1800) but mostly unnecessary.
All of the children sort of implies that one might consider just their arms
and legs but not heads. However, all the children gives the feeling of
completeness. Ignore me. But it does show that I am reading this stuff.

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

From: Gary Dismukes
Sent: Tuesday, March 24, 2015  5:42 PM

> A.18.10(2/4)  I would have preferred either "comprising" or "consisting of"
> rather than (perchance instead of) "comprising of". Fowler agrees with 
> me. I should have noticed that at editorial review but I was grumbling 
> about a comma then. But leave it, it's an example of the same sort of  
> construction as "inside of ".

I agree that this should be just "comprising" or "consisting of" (I somewhat
prefer the latter in this case).  I also dislike the position of the comma
in the sentence in question.  I would change it as follows:

  "... [comprising] {consisting} of a root node[,] and a set of internal
   nodes{,} each of which contains an element and pointers to ..."

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

From: Randy Brukardt
Sent: Tuesday, March 24, 2015  5:37 PM

Ah, but that would be wrong. A root node doesn't contain an element, only
internal nodes do. This wording is a bit weird in that we never say what the
root node contains (that's in the next paragraph), but that's intended.

John grumbled about the same thing [during editorial review, years
ago - Editor.], and I pointed out that the comma you want to delete is
"*very* important". He jokingly suggested that it be in bold. :-)

If we used parens to show the grouping here, it would be:

... consisting of (a root node), and (a set of internal nodes each of which
contains an element and pointers to ...)"

Maybe adding "(see below)" would help point out the forward reference.

   "... [comprising] {consisting} of a root node {(see below)}, and a set
   of internal nodes each of which contains an element and pointers to ..."

Dunno.

Given that this is introductory wording of minimal value, I'd rather leave it
subtle than hack around on it much more. But you'll get a chance on Thursday
(since the wording is already ARG approved).

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

From: Robert Dewar
Sent: Tuesday, March 24, 2015  5:42 PM

> I agree that this should be just "comprising" or "consisting
> of" (I somewhat prefer the latter in this case).

I think you should always avoid the word comprising, because of its legal
term-of-art meaning, which is including, but not limited to ...

so if you want to give a list intended to be exhaustive, always use consisting
of ..

His fleet of cars comprising two fords and three toyotas.

(his fleet actually has 72 toyota's, but the use of comprising is still
legally correct).

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

From: John Barnes
Sent: Wednesday, March 24, 2015  2:57 AM

Maybe "and also" rather than just "and" after the bold comma would help

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

From: Erhard Ploedereder
Sent: Monday, March 23, 2015  7:53 PM

Results of my review ... I have not yet followed John's suggestion of
reading everything in AA context, but I figured that you wanted stuff
now...not sure I can get to the AA review before Thu.

-=====================

for 6.1.1.

> Replace paragraph 7: [8652/0145]
> ...
> by:
> Within the expression for a Pre'Class or Post'Class aspect for a 
> primitive subprogram S of a tagged type T, a name that denotes a 
> formal parameter (or S'Result) of type T is interpreted as though it 
> had a (notional) type NT that is a formal derived type whose ancestor 
> type is T, with directly visible primitive operations. Similarly, a 
> name that denotes a formal access parameter (or S'Result) of type 
> access-to-T is interpreted as having type access-to-NT. The result of 
> this interpretation is that the only operations that can be applied to 
> such names are those defined for such a formal derived type. This 
> ensures that the expression is well-defined for any primitive 
> subprogram of a type descended from T.

The last sentence is clearly not RM style. Turn it into an AARM statement.

The penultimate sentence is neither, in my opinion (even if could pass as
derivable semantics in the RM). Still, I have the same suggestion.

...
========================

for 6.3.1.

> Replace paragraph 12: [8652/0147]
> ...
> by:
>  The default calling convention is protected for a protected 
> subprogram, a prefixed view of a subprogram with a synchronization 
> kind of By_Protected_Procedure, and for an access-to-subprogram type 
> with the reserved word protected in its definition.

Make that:

 The default calling convention is protected for a protected subprogram, for
  a prefixed view of a ...

to be uniform with the 1. and 3. case.

===========================

for 6.4.1.

> Insert after paragraph 6.25: [8652/0138] ...
> the new paragraph:
> If the mode is out, the actual parameter is a view conversion ....

I urge insertion after paragraph 5 instead. Several reasons:
- Para 6 all the way to 6.25 talks about alias rules, while the new text is
  about initialization.
- The text syntactically reads like a continuation of 6.25, but isn't.
- It remains unclear to which rules the "these rules also apply"-boilerplate
  is referring: only to the last two bullets or to all the aliasing rules as
  well.


> Replace paragraph 13.1: [8652/0138]
> ....
> by:
>  For a scalar type that has the Default_Value aspect specified, the 
> formal parameter is initialized from the value of the actual, without 
> checking that the value satisfies any constraint or any predicate, 
> except in the following case: if the actual parameter is a view 
> conversion and either  there exists no type (other than a root 
> numeric type) that is an ancestor of both the target type and the type 
> of the operand of the conversion; or  the Default_Value aspect is 
> unspecified for the type of the operand of the conversion then 
> Program_Error is raised;

The "except in the following case"-construct reads really awkwardly and is
quite ambiguous whether it refers to the checking or to the initializing.
But I have no good suggestion either. Best I could do is to replace it by
"...predicate. If, however, the actual ...."

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

Questions? Ask the ACAA Technical Agent