!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 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 #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.)

!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.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.]

(4) No wording change recommended.

(5) 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.

!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.

(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 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.

(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.

!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 3.8(18/2)

@drepl
Within the definition of a composite type, if a @fa<component_definition> or
@fa<discrete_subtype_definition> (see 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 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 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.

!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<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 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.

!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
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.>

!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 #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!

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