!standard 1.1.2(35) 22-02-03 AI22-0023-1/02 !standard 1.2(10/2) !standard 3.4.1(3/2) !standard 3.8(18/2) !standard 7.3.2(1/5) !standard 7.3.2(5/5) !standard 8.3(26/2) !standard 9.2(7) !standard 10.2.1(18/3) !standard A.18.2(88.1/3) !standard A.18.3(60.1/3) !standard A.18.3(158/2) !standard A.18.4(19.1/3) !standard A.18.4(81/2) !standard A.18.7(18.1/3) !standard A.18.7(102/2) !standard A.18.10(78/3) !standard B.3(60.8/2) !standard G.1.1(56) !standard G.1.1(57) !class presentation 22-01-19 !status Corrigendum 1-2022 22-02-03 !status ARG Approved 16-0-0 22-02-03 !status work item 22-01-19 !status received 21-04-12 !priority Low !difficulty Easy !subject Deferred presentation issues from the WG 9 review !summary Various deferred presentation issues are handled. !issue (1) [WG 9 comment #15] The second sentence of 10.2.1(18/3) is a very long, complex sentence (with 6 commas!); should it be restructured? (Yes.) (2) [WG 9 comment #22] It should be clearer that 1.1.2(35) does not make requirements (which would contradict 1.1.1 (12)), but rather are documentation of what certain performance characteristics are for an implementation. Change? (Yes.) (3) [WG 9 comment #26] In 3.4.1(3/2), use "one of" rather than "either" since this is a choice of three options, not two. Change? (Yes.) (4) [WG 9 comment #32] In 3.8(18/2), the first reference to 9.5.2 seems incorrect, maybe it should be 3.6? (No.) (5) [WG 9 comment #148] It would help readers if the intro of 7.3.2 were to explain that the aim of the Type_Invariant('Class) feature is to ensure that any object of this type/class satisfies the invariant when inspected or used by a client of the defining package, but the invariant does not have to be satisfied at each point within the operations of the defining package itself (where the full type declaration is visible). Therefore, the invariant is checked at the boundary between the defining package and its clients. Should this be done? (Yes.) (6) [WG 9 comment #150] 8.3(26/2) starts by stating several rules for various things, and then says "These rules also apply to dispatching operators declared in the visible part of an instance of a generic unit". The part "these rules" is confusing, because some of the rules stated earlier in the paragraph apply to type extensions or to context clauses, neither of which seems relevant to declarations of dispatching operations. Should this be clarified? (???.) (7) [WG 9 comment #154] The note 9.2(7) leaves me hanging in suspense: what happens if a task entry is called before the task is activated? Probably the caller task is blocked until the callee task either has been activated and accepts the entry call, or becomes terminated for some reason. Should the note should be extended to say what happens? (No.) (8) [WG 9 comment #177] In 7.3.3(4/5) the phrase "a name that denotes the declaration" is referring to the current instance of the type. But the analogous definition of Type_Invariant in 7.3.2(5/5) uses a different phrase: "the identifier of the first subtype of the associated type". It seems that the wording should be the same in these two places, should something be changed? (Yes.) (9) [WG 9 comment #178] In A.18.2(88.1/3) "It also may write..." would be better as "It may also write...". There are 20 instances of "may also" in the AARM but only a few "also may". And most of them are this same sentence but with vector replaced by set, map, and so on. These occur in A.18.3(60.1/3), A.18.4(19.1/3), A.18.7(18.1/3), and A.18.10(78/3). Change these? (Yes.) (10) [WG 9 comment #179] In A.18.2(253/2), we say "vector object" all in lower case. A.18.3(158/2) says "doubly-linked List object", with List capitalized. Similarly, A.18.4(81/2) says "a Map object" and A.18.7(102/2) says "a Set object", while A.18.10(229/3) says "a multiway tree object". Make these consistent? (Yes.) (11) G.1.1(56,57) refer to IEC 559:1989, however the current standard is ISO/IEC 60559:2020. Moreover, neither of these standards is referenced in the Normative References clause (where all referenced Standards should appear). Correctly handle these? (Yes.) (12) B.3(60.8/2) says: The result of Is_Nul_Terminated is True if Item contains char16_nul, and is False otherwise. But this is under a function that takes a char32_array, so this paragraph should mention char32_nul instead of char16_nul, right? (Yes.) !recommendation (See Summary.) !wording (1) Replace 10.2.1(18/3) with: If a library unit is declared pure, then the implementation is permitted to omit a call on a library-level subprogram of the library unit if the results are not needed after the call. In addition, the implementation may omit a call on such a subprogram and simply reuse the results produced by an earlier call on the same subprogram, provided that: * none of the parameters nor any object accessible via access values from the parameters have any part that is of a type whose full type is an immutably limited type; and * the addresses and values of all by-reference actual parameters, the values of all by-copy-in actual parameters, and the values of all objects accessible via access values from the parameters, are the same as they were at the earlier call. (2) Replace 1.1.2(35): Metrics that are specified for the time/space properties of the execution of certain language constructs. with: Documentation requirements for metrics of the time/space properties of the execution of certain language constructs. (3) Modify 3.4.1(3/2): Every type is {one of}[either] a *specific* type, a *class-wide* type, or a *universal* type. A specific type is one defined by a type_declaration, a formal_type_declaration, or a full type definition embedded in another construct. Class-wide and universal types are implicitly defined, to act as representatives for an entire class of types, as follows: [Move this to AI12-0437-1.] (4) Modify 3.8(18/2): Within the definition of a composite type, if a component_definition{ of a component_declaration} or discrete_subtype_definition{ of an entry_declaration for an entry family} (see 9.5.2) includes a name that denotes a discriminant of the type, or that is an attribute_reference whose prefix denotes the current instance of the type, the expression containing the name is called a *per-object expression*, and the constraint or range being defined is called a *per-object constraint*. For the elaboration of a component_definition of a component_declaration or the discrete_subtype_definition of an entry_declaration for an entry family[ (see 9.5.2)], if the component subtype is defined by an access_definition or if the constraint or range of the subtype_indication or discrete_subtype_definition is not a per-object constraint, then the access_definition, subtype_indication, or discrete_subtype_definition is elaborated. On the other hand, if the constraint or range is a per-object constraint, then the elaboration consists of the evaluation of any included expression that is not part of a per-object expression. Each such expression is evaluated once unless it is part of a named association in a discriminant constraint, in which case it is evaluated once for each associated discriminant. [Editor's note: This mainly repeats the more detailed wording found near the second reference to 9.5.2 for the first reference. It clarifies why we're referring to 9.5.2 instead of somewhere else.] (5) Add before 7.3.2(1/5): A type invariant is an assertion about the state of objects of a type exported by a package. The type invariant is enforced on objects used by clients of the package; it is generally not enforced on objects inside of the package. Similarly, a class-wide type invariant is an assertion of about the state of all objects of a class of types outside of the package defining the specific type of the class. (6) Modify 8.3(26/2): A non-overridable declaration is illegal if there is a homograph occurring immediately within the same declarative region that is visible at the place of the declaration, and is not hidden from all visibility by the non-overridable declaration. In addition, a type extension is illegal if somewhere within its immediate scope it has two visible components with the same name. Similarly, the context_clause for a compilation unit is illegal if it mentions (in a with_clause) some library unit, and there is a homograph of the library unit that is visible at the place of the compilation unit, and the homograph and the mentioned library unit are both declared immediately within the same declarative region. These rules {that apply to subprograms }also apply to dispatching operations declared in the visible part of an instance of a generic unit. However, they do not apply to other overloadable declarations in an instance; such declarations may have type conformant profiles in the instance, so long as the corresponding declarations in the generic were not type conformant. Add after AARM 8.3(26.k): AARM Ramification: The type extension component rule obviously does not apply to dispatching operations in an instance. However, the context clause rule could apply, as a compilation unit can be a subprogram. [Editor's note: I'm unsure that the wording added to the normative wording actually helps anything. Perhaps we should just add an AARM note like the one given??] (7) No wording change recommended. (8) Modify 7.3.2(5/5): Within an invariant expression, {a name that denotes the associated type declaration is interpreted as denoting}[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) nonabstract 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. (9) Modify A.18.2(88.1/3): Vector'Write for a Vector object V writes Length(V) elements of the vector to the stream. It {may }also[ may] write additional information about the vector. Modify A.18.3(60.1/3): List'Write for a List object L writes Length(L) elements of the list to the stream. It {may }also[ may] write additional information about the list. Modify A.18.4(19.1/3): Set'Write for a Set object S writes Length(S) elements of the set to the stream. It {may }also[ may] write additional information about the set. Modify A.18.7(18.1/3): Set'Write for a Set object S writes Length(S) elements of the set to the stream. It {may }also[ may] write additional information about the set. Modify A.18.10(78/3): Tree'Write for a Tree object @i writes Node_Count(@i) - 1 elements of the tree to the stream. It {may }also[ may] write additional information about the tree. (10) Modify A.18.3(158/2): No storage associated with a doubly-linked {list}[List] object shall be lost upon assignment or scope exit. Modify A.18.4(81/2): No storage associated with a {map}[Map] object shall be lost upon assignment or scope exit. Modify A.18.7(102/2): No storage associated with a {set}[Set] object shall be lost upon assignment or scope exit. (11) Add after 1.2(10/2): ISO/IEC 60559:2020, *Information technology -- Microprocessor Systems -- Floating-Point arithmetic* Modify G.1.1(56): Because the usual mathematical meaning of multiplication of a complex operand and a real operand is that of the scaling of both components of the former by the latter, an implementation should not perform this operation by first promoting the real operand to complex type and then performing a full complex multiplication. In systems that, in the future, support an Ada binding to {ISO/IEC 60559:2020}[IEC 559:1989], the latter technique will not generate the required result when one of the components of the complex operand is infinite. (Explicit multiplication of the infinite component by the zero component obtained during promotion yields a NaN that propagates into the final result.) Analogous advice applies in the case of multiplication of a complex operand and a pure-imaginary operand, and in the case of division of a complex operand by a real or pure-imaginary operand. Modify G.1.1(57): Likewise, because the usual mathematical meaning of addition of a complex operand and a real operand is that the imaginary operand remains unchanged, an implementation should not perform this operation by first promoting the real operand to complex type and then performing a full complex addition. In implementations in which the Signed_Zeros attribute of the component type is True (and which therefore conform to {ISO/IEC 60559:2020}[IEC 559:1989] in regard to the handling of the sign of zero in predefined arithmetic operations), the latter technique will not generate the required result when the imaginary component of the complex operand is a negatively signed zero. (Explicit addition of the negative zero to the zero obtained during promotion yields a positive zero.) Analogous advice applies in the case of addition of a complex operand and a pure-imaginary operand, and in the case of subtraction of a complex operand and a real or pure-imaginary operand. (12) Modify B.3(60.8/2): The result of Is_Nul_Terminated is True if Item contains {char32_nul}[char16_nul], and is False otherwise. !discussion We deferred all presentation comments on the Ada 2022 draft if they were on text that wasn't modified by Ada 2022 and that was not actually wrong. Most of these are in original Ada 95 wording that would be better written in line with our current wording standards. None of these should change the meaning of any Ada program. A few of these issues were raised after the WG 9 review. [Editor's note: I've included all of the changes suggested by the WG 9 review other than typography comments so that the ARG can consider them. Deciding to change nothing is an acceptable result for most of these issues, other than (11) and (12).] (1) A bulleted list makes this much easier to read. (2) Metrics is a special case of documentation requirements and this paragraph should say that. (3) Unclear to the author that this is an improvement. (4) The only way that a discrete_subtype_definition can appear in a composite type is as the entry family of and entry declaration. (They also appear in chunk_specification, constrained_array_definition, and loop_parameter_specification, but none of those can appear in a component_definition or protected_element_declaration.) This is mentioned in the next sentence of the paragraph, but that's a bit late. (5) Most subclauses have some sort of introduction, it's unusual that this one does not. (6) The last two sentences of 8.3(26/2) are original Ada 95 wording. At that time, the rule about type extension components did not exist, and the context clause rule was only about subunits. In that case, it is fairly clear how both of these rules could apply in the generic instance case (since a subunit can be a completion of a dispatching operation). Later bug fixes broadened the subunit rule to any compilation unit, and the type extension rule was added. After those changes, the connection to the later sentences was lost. (7) This subclause occurs before the description of entry calls, so we don't want to say very much about the mechanism of the calls. Indeed, it's unclear that we should be talking about entry calls at all here. But given that this note is unchanged from original Ada 95, there seems to be little reason to make a change at this time (either deleting or expanding the note). (8) 8.6 (17-18), which formally define "current instance" of a type, talk of a "usage name" denoting "the same declaration of the type". So, the use of "identifier" in 7.3.2(5/4) is too narrow (it does not include renames, for instance). We change the wording to be more like that of 7.3.3(4/5). Note that this text is considered Redundant and should not affect the semantics of the language. (9) As "may also" is more common in the RM, we change the text to use that. (10) As the text reads better without the capital letters, we change the wording to lower case all of the text in these cases. (11) As Standards should not reference superseded Standards unless absolutely necessary, we update the uses to point to ISO/IEC 60559:2020. We also add this Standard to the list in 1.2 Normative References. An alternative would be to eliminate the references from G.1.1(56-57). The first use is especially suspicious, given that it references something that might happen "in the future" (and which was rejected for Standardization in 2004 - see AI95-0315-1). However, since most hardware is IEEE today, it seems reasonable to retain the advice. (12) A char32_array contains char32_t characters, and thus we need to use the char32_t version of nul (char32_nul). !corrigendum 1.1.2(35) @drepl Metrics that are specified for the time/space properties of the execution of certain language constructs. @dby Documentation requirements for metrics of the time/space properties of the execution of certain language constructs. !corrigendum 1.2(10/2) @dinsa ISO/IEC TR 19769:2004, @i. @dinst ISO/IEC 60559:2020, @i !corrigendum 3.4.1(3/2) @drepl Every type is either a @i type, a @i type, or a @i type. A specific type is one defined by a @fa, a @fa, or a full type definition embedded in another construct. Class-wide and universal types are implicitly defined, to act as representatives for an entire class of types, as follows: @dby Every type is one of a @i type, a @i type, or a @i type. A specific type is one defined by a @fa, a @fa, or a full type definition embedded in another construct. Class-wide and universal types are implicitly defined, to act as representatives for an entire class of types, as follows: !corrigendum 3.8(18/2) @drepl Within the definition of a composite type, if a @fa or @fa (see 9.5.2) includes a @fa that denotes a discriminant of the type, or that is an @fa whose @fa denotes the current instance of the type, the expression containing the @fa is called a @i, and the @fa or @fa being defined is called a @i. For the elaboration of a @fa of a @fa or the @fa of an @fa for an entry family (see 9.5.2), if the component subtype is defined by an @fa or if the @fa or @fa of the @fa or @fa is not a per-object constraint, then the @fa, @fa, or @fa is elaborated. On the other hand, if the @fa or @fa is a per-object constraint, then the elaboration consists of the evaluation of any included expression that is not part of a per-object expression. Each such expression is evaluated once unless it is part of a named association in a discriminant constraint, in which case it is evaluated once for each associated discriminant. @dby Within the definition of a composite type, if a @fa of a @fa or the @fa of an @fa for an entry family (see 9.5.2) includes a @fa that denotes a discriminant of the type, or that is an @fa whose @fa denotes the current instance of the type, the expression containing the @fa is called a @i, and the @fa or @fa being defined is called a @i. For the elaboration of a @fa of a @fa or the @fa of an @fa for an entry family, if the component subtype is defined by an @fa or if the @fa or @fa of the @fa or @fa is not a per-object constraint, then the @fa, @fa, or @fa is elaborated. On the other hand, if the @fa or @fa is a per-object constraint, then the elaboration consists of the evaluation of any included expression that is not part of a per-object expression. Each such expression is evaluated once unless it is part of a named association in a discriminant constraint, in which case it is evaluated once for each associated discriminant. !corrigendum 7.3.2(1/5) @dinsb For a private type, private extension, or interface, the following language-defined assertion aspects may be specified with an @fa (see 13.1.1): @dinst A type invariant is an assertion about the state of objects of a type exported by a package. The type invariant is enforced on objects used by clients of the package; it is generally not enforced on objects inside of the package. Similarly, a class-wide type invariant is an assertion of about the state of all objects of a class of types outside of the package defining the specific type of the class. !corrigendum 7.3.2(5/5) @drepl 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 @i, the type of this current instance is @i. Within an invariant expression for the Type_Invariant'Class aspect of a type @i, the type of this current instance is interpreted as though it had a (notional) nonabstract type @i that is a visible formal derived type whose ancestor type is @i. 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. @dby Within an invariant expression, a name that denotes the associated type declaration is interpreted as denoting the current instance of the type. Within an invariant expression for the Type_Invariant aspect of a type @i, the type of this current instance is @i. Within an invariant expression for the Type_Invariant'Class aspect of a type @i, the type of this current instance is interpreted as though it had a (notional) nonabstract type @i that is a visible formal derived type whose ancestor type is @i. 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 8.3(26/2) @drepl A non-overridable declaration is illegal if there is a homograph occurring immediately within the same declarative region that is visible at the place of the declaration, and is not hidden from all visibility by the non-overridable declaration. In addition, a type extension is illegal if somewhere within its immediate scope it has two visible components with the same name. Similarly, the @fa for a compilation unit is illegal if it mentions (in a @fa) some library unit, and there is a homograph of the library unit that is visible at the place of the compilation unit, and the homograph and the mentioned library unit are both declared immediately within the same declarative region. These rules also apply to dispatching operations declared in the visible part of an instance of a generic unit. However, they do not apply to other overloadable declarations in an instance; such declarations may have type conformant profiles in the instance, so long as the corresponding declarations in the generic were not type conformant. @dby A non-overridable declaration is illegal if there is a homograph occurring immediately within the same declarative region that is visible at the place of the declaration, and is not hidden from all visibility by the non-overridable declaration. In addition, a type extension is illegal if somewhere within its immediate scope it has two visible components with the same name. Similarly, the @fa for a compilation unit is illegal if it mentions (in a @fa) some library unit, and there is a homograph of the library unit that is visible at the place of the compilation unit, and the homograph and the mentioned library unit are both declared immediately within the same declarative region. These rules that apply to subprograms also apply to dispatching operations declared in the visible part of an instance of a generic unit. However, they do not apply to other overloadable declarations in an instance; such declarations may have type conformant profiles in the instance, so long as the corresponding declarations in the generic were not type conformant. !corrigendum 10.2.1(18/3) @drepl If a library unit is declared pure, then the implementation is permitted to omit a call on a library-level subprogram of the library unit if the results are not needed after the call. In addition, the implementation may omit a call on such a subprogram and simply reuse the results produced by an earlier call on the same subprogram, provided that none of the parameters nor any object accessible via access values from the parameters have any part that is of a type whose full type is an immutably limited type, and the addresses and values of all by-reference actual parameters, the values of all by-copy-in actual parameters, and the values of all objects accessible via access values from the parameters, are the same as they were at the earlier call. This permission applies even if the subprogram produces other side effects when called. @dby In addition, the implementation may omit a call on such a subprogram and simply reuse the results produced by an earlier call on the same subprogram, provided that: @xbullet @xbullet !corrigendum A.18.2(88.1/3) @drepl Vector'Write for a Vector object @i writes Length(@i) elements of the vector to the stream. It also may write additional information about the vector. @dby Vector'Write for a Vector object @i writes Length(@i) elements of the vector to the stream. It may also write additional information about the vector. !corrigendum A.18.3(60.1/3) @drepl List'Write for a List object @i writes Length(@i) elements of the list to the stream. It also may write additional information about the list. @dby List'Write for a List object @i writes Length(@i) elements of the list to the stream. It may also write additional information about the list. !corrigendum A.18.3(158/2) @drepl No storage associated with a doubly-linked List object shall be lost upon assignment or scope exit. @dby No storage associated with a doubly-linked list object shall be lost upon assignment or scope exit. !corrigendum A.18.4(19.1/3) @drepl Map'Write for a Map object @i writes Length(@i) elements of the map to the stream. It also may write additional information about the map. @dby Map'Write for a Map object @i writes Length(@i) elements of the map to the stream. It may also write additional information about the map. !corrigendum A.18.4(81/2) @drepl No storage associated with a Map object shall be lost upon assignment or scope exit. @dby No storage associated with a map object shall be lost upon assignment or scope exit. !corrigendum A.18.7(18.1/3) @drepl Set'Write for a Set object @i writes Length(@i) elements of the set to the stream. It also may write additional information about the set. @dby Set'Write for a Set object @i writes Length(@i) elements of the set to the stream. It may also write additional information about the set. !corrigendum A.18.7(102/2) @drepl No storage associated with a Set object shall be lost upon assignment or scope exit. @dby No storage associated with a set object shall be lost upon assignment or scope exit. !corrigendum A.18.10(78/3) @drepl Tree'Write for a Tree object @i writes Node_Count(@i) - 1 elements of the tree to the stream. It also may write additional information about the tree. @dby Tree'Write for a Tree object @i writes Node_Count(@i) - 1 elements of the tree to the stream. It may also write additional information about the tree. !corrigendum B.3(60.8/2) @drepl @xindent @dby @xindent !corrigendum G.1.1(56) @drepl Because the usual mathematical meaning of multiplication of a complex operand and a real operand is that of the scaling of both components of the former by the latter, an implementation should not perform this operation by first promoting the real operand to complex type and then performing a full complex multiplication. In systems that, in the future, support an Ada binding to IEC 559:1989, the latter technique will not generate the required result when one of the components of the complex operand is infinite. (Explicit multiplication of the infinite component by the zero component obtained during promotion yields a NaN that propagates into the final result.) Analogous advice applies in the case of multiplication of a complex operand and a pure-imaginary operand, and in the case of division of a complex operand by a real or pure-imaginary operand. @dby Because the usual mathematical meaning of multiplication of a complex operand and a real operand is that of the scaling of both components of the former by the latter, an implementation should not perform this operation by first promoting the real operand to complex type and then performing a full complex multiplication. In systems that, in the future, support an Ada binding to ISO/IEC 60559:2020, the latter technique will not generate the required result when one of the components of the complex operand is infinite. (Explicit multiplication of the infinite component by the zero component obtained during promotion yields a NaN that propagates into the final result.) Analogous advice applies in the case of multiplication of a complex operand and a pure-imaginary operand, and in the case of division of a complex operand by a real or pure-imaginary operand. !corrigendum G.1.1(57) @drepl Likewise, because the usual mathematical meaning of addition of a complex operand and a real operand is that the imaginary operand remains unchanged, an implementation should not perform this operation by first promoting the real operand to complex type and then performing a full complex addition. In implementations in which the Signed_Zeros attribute of the component type is True (and which therefore conform to IEC 559:1989 in regard to the handling of the sign of zero in predefined arithmetic operations), the latter technique will not generate the required result when the imaginary component of the complex operand is a negatively signed zero. (Explicit addition of the negative zero to the zero obtained during promotion yields a positive zero.) Analogous advice applies in the case of addition of a complex operand and a pure-imaginary operand, and in the case of subtraction of a complex operand and a real or pure-imaginary operand. @dby Likewise, because the usual mathematical meaning of addition of a complex operand and a real operand is that the imaginary operand remains unchanged, an implementation should not perform this operation by first promoting the real operand to complex type and then performing a full complex addition. In implementations in which the Signed_Zeros attribute of the component type is True (and which therefore conform to ISO/IEC 60559:2020 in regard to the handling of the sign of zero in predefined arithmetic operations), the latter technique will not generate the required result when the imaginary component of the complex operand is a negatively signed zero. (Explicit addition of the negative zero to the zero obtained during promotion yields a positive zero.) Analogous advice applies in the case of addition of a complex operand and a pure-imaginary operand, and in the case of subtraction of a complex operand and a real or pure-imaginary operand. !ACATS test No tests are needed for presentation changes; no semantic change is intended here. !appendix From: Brad Moore WG 9 Review issue #15 - April 12, 2021 [Comment on 10.2.1(18/3).] " In addition, the implementation may omit a call on such a subprogram and simply reuse the results produced by an earlier call on the same subprogram, provided that none of the parameters nor any object accessible via access values from the parameters have any part that is of a type whose full type is an immutably limited type, and the addresses and values of all by-reference actual parameters, the values of all by-copy-in actual parameters, and the values of all objects accessible via access values from the parameters, are the same as they were at the earlier call." Too long complex, try reading this aloud (6 commas, for instance) suggest breaking down into multiple sentences. Perhaps a bulleted list as in; " In addition, the implementation may omit a call on such a subprogram and simply reuse the results produced by an earlier call on the same subprogram, provided that; * none of the parameters nor any object accessible via access values from the parameters have any part that is of a type whose full type is an immutably limited type * the addresses and values of all by-reference actual parameters, the values of all by-copy-in actual parameters, and the values of all objects accessible via access values from the parameters, are the same as they were at the earlier call." **************************************************************** From: Randy Brukardt WG 9 Review issue #15 - May 6, 2021 This rule is unchanged from Ada 2012 (and barely changed from Ada 2005). I didn't think we are "improving" existing text unless it is wrong at this stage; I'll recheck on that. (There is a large number of existing paragraphs that could be "improved", but every improvement also carries a risk of introducing a bug, and given this is the very last review of this version, any mistakes will live as long as Ada does.) **************************************************************** From: Randy Brukardt WG 9 Review issue #15 - May 9, 2021 There doesn't seem to be much interest (from the people I polled) in making non-required changes to ancient wording at this time. If I have time, I will write these things up for future use, but unlikely in this revision. **************************************************************** From: Jeff Cousins WG 9 Review issue #22 - April 16, 2021 [Comment on 1.1.2(35).] Maybe make clearer that these are not requirements (which would contradict 1.1.1 (12)), but documentation of what certain performance characteristics are for an implementation. **************************************************************** From: Randy Brukardt WG 9 Review issue #22 - May 25, 2021 This is an original Ada 95 paragraph, the text is not wrong (at least as far as I can tell), and the whole idea of metrics is dubious. This is deferred as improving existing, unchanged text is out of bounds for this review, especially in this case where we're more likely to cause trouble than fix it. **************************************************************** From: Jeff Cousins WG 9 Review issue #26 - April 16, 2021 [Comment on 3.4.1(3/2).] "one of" rather than "either" since a choice of 3 options, not 2. **************************************************************** From: Randy Brukardt WG 9 Review issue #26 - May 25, 2021 I think I prefer "either" here, even if it is strictly incorrect. In any case, this is old text that is not wrong (in an Ada sense), so it is out of bounds for this review. Thus it is deferred, see issue #15 for more. **************************************************************** From: Jeff Cousins WG 9 Review issue #32 - April 16, 2021 [Comment on 3.8(18/2).] The first reference to 9.5.2 seems incorrect, maybe it should be 3.6? **************************************************************** From: Randy Brukardt WG 9 Review issue #32 - May 25, 2021 I believe this cross-reference is correct, since it is referring to the discrete_subtype_definition of an entry_declaration (even though that isn't said explicitly) -- a discriminant is not allowed in any other kind of discrete_subtype_definition. I could agree that the wording isn't the best -- the explanation is with the second use of the syntax! But this is an Ada 2005 paragraph unchanged by Ada 202x, and it is not wrong, thus improving it is out of bounds for this review. I've marked it deferred (although No Action might be better). **************************************************************** From: Pat Rogers WG 9 Review issue #93 - April 18, 2021 [Comment on G.2.4 (10).] This para has the dreaded radix plus minute superscript which runs over the end of line and looks awkward. And I expect most readers are not aware that the subscript is within floor brackets. Maybe the best thing to do is to simply make it a displayed expression on a line of its own and maybe use a vertical arrow to indicate the index so that the index does not have to be reduced to give something like ..... shall be at least: EF.Float_Type'Machine_Radix ^ [EF.Float_Type'Machine_Mantissa/2] Sorry I couldn't find the floor brackets in Word. **************************************************************** From: Randy Brukardt WG 9 Review issue #93 - May 28, 2021 If you use the zoom button/slider on you PDF reader, this is perfectly readable. The typography is a bit problematic, but it has been that way in all of the editions of this century, so it is hardly a pressing issue. And it is certainly not wrong and not a recently added/modified package, so this comment is deferred. [Editor's note: The typography choices that would be appropriate both in Word (as required by ISO) and in HTML are rather limited. And this seems to be a minor problem not worth inventing (and documenting) a new notation. So this is getting No Action.] **************************************************************** From: Niklas Holsti WG 9 Review issue #148 - May 20, 2021 [Comment on 7.3.2.] It might help readers if the intro were to explain that the aim of the Type_Invariant('Class) feature is to ensure that any object of this type/class satisfies the invariant when inspected or used by a client of the defining package, but the invariant does not have to be satisfied at each point within the operations of the defining package itself (where the full type declaration is visible). Therefore, the invariant is checked at the boundary between the defining package and its clients. Similar text is now in the Ramification RM 7.3.2 (23.a/5), but that is quite late in the section and is not visible in the non-annotated RM. **************************************************************** From: Randy Brukardt WG 9 Review issue #148 - May 21, 2021 This makes sense, but since the existing text (of which there is none!) is neither new nor wrong, this is out of bounds for this review. As such, it will be deferred. See issue #15 for more on this topic. **************************************************************** From: Niklas Holsti WG 9 Review issue #150 - May 20, 2021 [Comment on 8.3(26/2).] The paragraph starts by stating several rules for various things, and then says "These rules also apply to dispatching operators declared in the visible part of an instance of a generic unit". The part "these rules" is confusing, because some of the rules stated earlier in the paragraph apply to type extensions or to context clauses, neither of which seems relevant to declarations of dispatching operations. It seems that only the first rule stated in this paragraph, about non-overridable declarations, can apply to declarations of dispatching operations. It would be clearer to separate the rules for type extensions and context clauses into their own paragraphs (and, in the annotated RM, distribute the annotations accordingly). On second thought, perhaps the point about the dispatching operations is that such an operation could be the "homograph of the library unit" that is involved in the rule for context clauses. But at least the rule about type extensions seems irrelevant to dispatching operations. **************************************************************** From: Randy Brukardt WG 9 Review issue #150 - May 21, 2021 It's fairly clear from the AARM notes that both the first and third rules could apply to a dispatching operation (since compilation units can be a subprogram). And it is harmless (even if confusing) to apply the second rule in that case (it obviously only applies to types, so it doesn't ever trigger for a subprogram). As such, there is nothing actually wrong here, and this is old (Ada 2005) text. Thus this suggestion is out of bounds for this review and it is marked deferred. See issue #15 for more on this topic. **************************************************************** From: Niklas Holsti WG 9 Review issue #154 - May 20, 2021 [Comment on 9.2(7).] This note leaves me hanging in suspense: what happens if a task entry is called before the task is activated? I believe the caller task is blocked until the callee task either has been activated and accepts the entry call, or becomes terminated for some reason. For clarity, the note should be extended to say what happens. **************************************************************** From: Tucker Taft WG 9 Review issue #154 - May 20, 2021 This is original wording, and isn't a "bug," so addressing this comment should probably be postponed until after the Ada 2022 standard is released. At this point we are focused on fixing (easy ;-) bugs. Trying to improve the presentation is a never-ending process, which will continue until well past Ada 2099... **************************************************************** From: Randy Brukardt WG 9 Review issue #154 - May 21, 2021 Agreed. See also my replies to issue #15. **************************************************************** From: Randy Brukardt WG 9 Review issue #177 - May 21, 2021 Splitting an issue originally raised by Miklas Holsti in issue #149 (May 20th), paraphrased: In 7.3.3(4/5) the phrase "a name that denotes the declaration" is referring to the current instance of the type. But the analogous definition of Type_Invariant in RM 7.3.2(5/4) uses a different phrase: "the identifier of the first subtype of the associated type". Why is the wording different in these two places, and which is correct? **************************************************************** From: Randy Brukardt WG 9 Review issue #177 - May 27, 2021 Later, Miklas pointed out that we hadn't addressed this question: Interesting discussions, but no-one has commented on the second part of my original issue, which is that the analogous definition of the current instance for Type_Invariant in RM 7.3.2 (5/4) uses a different phrase: "the identifier of the first subtype of the associated type", instead of "a name that denotes the declaration". The former suggests a direct comparison of identifier strings on the lexical level, as for the identifiers that often follow "end" keywords, while the latter suggests the outcome of name resolution. Is the wording intentionally different? Or would it be better to use the same wording in both places? I haven't checked all the other similar rules in the RM. **************************************************************** From: Randy Brukardt WG 9 Review issue #177 - May 27, 2021 This is a separate issue from #149, so I've split it to treat it separately. The wording in question (7.3.2(5/4)) is marked Redundant, which means that it is supposed to follow from other rules and be purely informational. The other wording (7.3.3(4/5)) is not marked that, probably because it is tied up in the notional type NT wording. Probably these should be worded similarly, and the 7.3.2(5/4) wording be changed. But it is not wrong, and it is original Ada 2012 wording (it predates the 8.6 wording that makes it redundant) -- which makes it out of bounds for this review. As noted elsewhere (see reply to #15), "improving" wording has a significant possibility of introducing errors where there are none, and wording that has 8+ years of history cannot be a major problem in understanding (as if it was we would have already heard about it), So this issue, like all wording improvements is marked Deferred (we will gather these up and look at them post Ada 202x). **************************************************************** From: Tucker Taft WG 9 Review issue #177 - May 28, 2021 I agree with your conclusion -- the wording is inconsistent, but not misleading, and better not to try to "fix" it now when we know how frequently "benign" last-minute changes can create new problems. But definitely something to revisit later. Thanks, Niklas, for your very careful reading! **************************************************************** From: Randy Brukardt WG 9 Review issue #178 - June 3, 2021 Split from Issue #120, by John Barnes, May 5th. A.18.2 88.1/3 "It also may write..." perhaps better as "It may also write..." There are 20 instances of "may also" in the AARM but only a few "also may". And most of them are this same sentence but with vector replaced by set, map, and so on. A.18.3(60.1/3), A.18.4(19.1/3), A.18.7(18.1/3), A.18.10(78/3). For the record the AARM ones are in 4.5.7 (7.j/3), 5.5.2 (8.a/5), and 12.5.1 (28.c/2). **************************************************************** From: Randy Brukardt WG 9 Review issue #178 - June 3, 2021 The wording here is unchanged Ada 2012 wording that is not wrong. “Improvements” in such wording are considered out of bounds for this review. See also my reply to #15. **************************************************************** From: Randy Brukardt WG 9 Review issue #179 - June 3, 2021 Split from #121, #122, #123, by John Barnes, May 5th. A.18.3(158/2) perhaps say "doubly-linked list object" all in lower case to match vectors etc A,18.4(81/2) maybe "a map object" all in lower case to match others A.18.7(102/2) maybe "a set object" in lower case to match others **************************************************************** From: Randy Brukardt WG 9 Review issue #179 - June 3, 2021 This is original unmodified Ada 2005 wording. Moreover, of that Ada 2005 wording, only vectors is in lower case. It would make just as much sense to modify the wording to put Vector and Tree in upper case; that would be more consistent with the original wording. In any case, this is unmodified wording that is not wrong in any case; "improvements" of existing wording is out of bounds for this review. Also see my response to #15 for more. **************************************************************** From: Jean-Pierre Rosen Sent: Sunday, July 11, 2021 4:11 AM (noticed as a side effect of my reviews for WG23/vulnerabilities) G.1.1(56,57) refer to IEC 559:1989, however the current standard is ISO/IEC 60559:2020. Moreover, neither of these standards is referenced in the index. [Editor's note: I think he means the "Normative References" clause, which is supposed to list all of the referenced standards.] **************************************************************** From: Tucker Taft Sent: Tuesday, November 16, 2021 6:56 AM Yannick Moy noticed the following typo in http://www.ada-auth.org/standards/2xrm/html/RM-B-3.html : 60.7/2 function Is_Nul_Terminated (Item : in char32_array) return Boolean; 60.8/2 The result of Is_Nul_Terminated is True if Item contains char16_nul, and is False otherwise. The line above should mention char32_nul instead of char16_nul. ****************************************************************