Version 1.2 of ai22s/ai22-0023-1.txt
!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<T> writes Node_Count(@i<T>) - 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)
Replace the paragraph:
Metrics that are specified for the time/space properties of the execution of
certain language constructs.
by:
Documentation requirements for metrics of the time/space properties of the
execution of certain language constructs.
!corrigendum 1.2(10/2)
Insert after the paragraph:
ISO/IEC TR 19769:2004, Information technology — Programming languages,
their environments and system software interfaces — Extensions for the
programming language C to support new character data types.
the new paragraph:
ISO/IEC 60559:2020, Information technology — Microprocessor Systems
— Floating-Point arithmetic
!corrigendum 3.4.1(3/2)
Replace the paragraph:
Every type is 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:
by:
Every type is one of 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:
!corrigendum 3.8(18/2)
Replace the paragraph:
Within the definition of a composite type, if a component_definition or
discrete_subtype_definition (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.
by:
Within the definition of a composite type, if a component_definition of a
component_declaration or the 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, 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.
!corrigendum 7.3.2(1/5)
Insert before the paragraph:
For a private type, private extension, or interface, the following
language-defined assertion aspects may be specified with an
aspect_specification (see 13.1.1):
the new paragraph:
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)
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 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.
by:
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 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.
!corrigendum 8.3(26/2)
Replace the paragraph:
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 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.
by:
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.
!corrigendum 10.2.1(18/3)
Replace the paragraph:
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.
by:
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.
!corrigendum A.18.2(88.1/3)
Replace the paragraph:
Vector'Write for a Vector object V writes Length(V) elements of the vector to the
stream. It also may write additional information about the vector.
by:
Vector'Write for a Vector object V writes Length(V) elements of the vector to the
stream. It may also write additional information about the vector.
!corrigendum A.18.3(60.1/3)
Replace the paragraph:
List'Write for a List object L writes Length(L) elements of the list to the
stream. It also may write additional information about the list.
by:
List'Write for a List object L writes Length(L) elements of the list to the
stream. It may also write additional information about the list.
!corrigendum A.18.3(158/2)
Replace the paragraph:
No storage associated with a doubly-linked List object shall be lost
upon assignment or scope exit.
by:
No storage associated with a doubly-linked list object shall be lost
upon assignment or scope exit.
!corrigendum A.18.4(19.1/3)
Replace the paragraph:
Map'Write for a Map object M writes Length(M) elements of the map to the
stream. It also may write additional information about the map.
by:
Map'Write for a Map object M writes Length(M) elements of the map to the
stream. It may also write additional information about the map.
!corrigendum A.18.4(81/2)
Replace the paragraph:
No storage associated with a Map object shall be lost upon assignment
or scope exit.
by:
No storage associated with a map object shall be lost upon assignment
or scope exit.
!corrigendum A.18.7(18.1/3)
Replace the paragraph:
Set'Write for a Set object S writes Length(S) elements of the set to the
stream. It also may write additional information about the set.
by:
Set'Write for a Set object S writes Length(S) elements of the set to the
stream. It may also write additional information about the set.
!corrigendum A.18.7(102/2)
Replace the paragraph:
No storage associated with a Set object shall be lost upon assignment
or scope exit.
by:
No storage associated with a set object shall be lost upon assignment
or scope exit.
!corrigendum A.18.10(78/3)
Replace the paragraph:
Tree'Write for a Tree object T writes Node_Count(T) - 1 elements of the
tree to the stream. It also may write additional information about the tree.
by:
Tree'Write for a Tree object T writes Node_Count(T) - 1 elements of the
tree to the stream. It may also write additional information about the tree.
!corrigendum B.3(60.8/2)
Replace the paragraph:
The result of Is_Nul_Terminated is True if Item contains char16_nul,
and is False otherwise.
by:
The result of Is_Nul_Terminated is True if Item contains char32_nul,
and is False otherwise.
!corrigendum G.1.1(56)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
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.
by:
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.
****************************************************************
Questions? Ask the ACAA Technical Agent