AI22-0023-1
!standard 1.1.2(35) 22-02-04 AI22-0023-1/02
!standard 3.8(18/2)
!standard 7.3.2(5/5)
!standard 9.2(7)
!standard 10.2.1(18/3)
!class presentation 22-01-19
!status Amendment 1-2022 22-02-03
!status WG9 Approved 22-10-18
!status ARG Approved 16-0-0 22-02-03
!status work item 22-01-19
!status received 21-04-12
!submitter Brad Moore, Jeff Cousins, Pat Rogers, Niklas Holsti
!priority Low
!difficulty Easy
!qualifier Clarification
!subject Deferred presentation issues from the WG 9 review
Various deferred presentation issues are handled.
(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 #32] In 3.8(18/2), the first reference to 9.5.2 seems incorrect, maybe it should be 3.6? (No.)
(4) [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.)
(5) [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.)
(See Summary.)
Replace 10.2.1(18/3) with: (1)
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:
Replace 1.1.2(35): (2)
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.
Modify 3.8(18/2): (3)
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.]
No wording change recommended for (4).
Modify 7.3.2(5/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.
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.
(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) The only way that a discrete_subtype_definition can appear in a composite type is as the entry family of an 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.
(4) 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).
(5) 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.
@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.
@drepl
Within the definition of a composite type, if a @fa{component_definition} or
@fa{discrete_subtype_definition} (see @ref{9.5.2}) includes a @fa{name} that denotes
a discriminant of the type, or that is an @fa{attribute_reference} whose
@fa{prefix} denotes the current instance of the type, the expression containing the
@fa{name} is called a @i{per-object expression}, and the @fa{constraint} or
@fa{range} being defined is called a @i{per-object constraint}. For the
elaboration of a @fa{component_definition} of a @fa{component_declaration} or
the @fa{discrete_subtype_definition} of an @fa{entry_declaration} for an entry
family (see @ref{9.5.2}), if the component subtype is defined by an
@fa{access_definition} or if the @fa{constraint} or @fa{range} of the
@fa{subtype_indication} or @fa{discrete_subtype_definition} is not a per-object
constraint, then the @fa{access_definition}, @fa{subtype_indication}, or
@fa{discrete_subtype_definition} is elaborated. On the other hand, if the
@fa{constraint} or @fa{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.
@dby
Within the definition of a composite type, if a @fa{component_definition} of a
@fa{component_declaration} or the @fa{discrete_subtype_definition} of an
@fa{entry_declaration} for an entry family (see @ref{9.5.2}) includes a @fa{name} that
denotes a discriminant of the type, or that is an @fa{attribute_reference} whose
@fa{prefix} denotes the current instance of the type, the expression containing the
@fa{name} is called a @i{per-object expression}, and the @fa{constraint} or
@fa{range} being defined is called a @i{per-object constraint}. For the
elaboration of a @fa{component_definition} of a @fa{component_declaration} or
the @fa{discrete_subtype_definition} of an @fa{entry_declaration} for an entry
family, if the component subtype is defined by an
@fa{access_definition} or if the @fa{constraint} or @fa{range} of the
@fa{subtype_indication} or @fa{discrete_subtype_definition} is not a per-object
constraint, then the @fa{access_definition}, @fa{subtype_indication}, or
@fa{discrete_subtype_definition} is elaborated. On the other hand, if the
@fa{constraint} or @fa{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.
@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{T}, the type of this current instance is @i{T}. Within
an invariant expression for the Type_Invariant'Class aspect of a type
@i{T}, the type of this current instance is interpreted as though it
had a (notional) nonabstract type @i{NT} that is a visible formal derived
type whose ancestor type is @i{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.
@dby
Within an invariant expression, a @fa{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{T}, the type of this current instance is @i{T}. Within
an invariant expression for the Type_Invariant'Class aspect of a type
@i{T}, the type of this current instance is interpreted as though it
had a (notional) nonabstract type @i{NT} that is a visible formal derived
type whose ancestor type is @i{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.
@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
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:
@xbullet{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}
@xbullet{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.}
No tests are needed for presentation changes; no semantic change is intended here.
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 #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 #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!
****************************************************************