AI22-0018-1
!standard 4.3.5(24/5) 22-09-06 AI22-0018-1/05
!standard 4.3.5(26/5)
!standard 4.3.5(38/5)
!standard 4.3.5(39/5)
!standard 4.9(8.1/5)
!standard 13.1(0.1/3)
!class binding interpretation 21-11-12
!status Amendment 1-2022 22-01-14
!status WG9 Approved 22-10-18
!status ARG Approved 13-0-0 21-11-18
!status work item 21-11-12
!status received 21-11-12
!submitter Randy Brukardt
!priority Low
!difficulty Easy
!qualifier Error
!subject Easy fixes to Ada 2022
A number of simple changes are suggested for Ada 2022.
(1) We decided in AI12-0396-1 that all aspects are either representation or operational aspects. However, not all aspects identify which class they are, for instance, Preelaborable_Initialization does not. That makes it hard to determine whether the rules are properly specified. Should this be fixed? (Yes.)
(2) In 4.3.5(24/5), we mention every kind of aggregate other than a named aggregate with an iterator_specification without key_expressions. We intend no restriction on those, but given that we mention null aggregates (which also have no restriction), it seems like a mistake not to mention the last case. Should some wording be added? (Yes.)
(3) In 4.3.5(26/5), we disallow discrete_ranges in key choices for container aggregates implemented by Add_Named. But there seems to be no reason for this restriction. A discrete_range is allowed in a loop_parameter_specification, so the needed implementation exists. Should it be dropped? (Yes.)
(4) 4.9(8.1/5) mentions the "Nonblocking attribute", but that was removed during a rewrite of the nonblocking model. Should this rule be dropped? (Yes.)
(1) Add a rule such that an aspect that is not explicitly specified as a representation aspect is automatically assumed to be an operational aspect.
(2) Add a sentence about the missing kind of aggregate.
(3) Drop the restriction. Also fix-up the wording about calls to Empty to reflect the removal of the restriction.
(4) Drop a rule about a nonexistent attribute.
Modify 13.1(0.1/3): (1)
[Redundant: Two kinds of aspects of entities can be specified: representation aspects and operational aspects. Representation aspects affect how the types and other entities of the language are to be mapped onto the underlying machine. Operational aspects determine other properties of entities.] {When not specified otherwise, an aspect is defined to be an operational aspect.}
[Note: As always, the square brackets here indicate that only the existing text is redundant, rather than representating a deletion.]
Modify 4.3.5(24/5): (2)
The expected type for a positional_container_aggregate shall have an Aggregate aspect that includes a specification for an Add_Unnamed procedure or an Assign_Indexed procedure. The expected type for a named_container_aggregate that contains one or more iterated_element_associations with a key_expression shall have an Aggregate aspect that includes a specification for the Add_Named procedure. The expected type for a named_container_aggregate that contains one or more key_choice_lists shall have an Aggregate aspect that includes a specification for the Add_Named or Assign_Indexed procedure. [Redundant: {For other kinds of named_container_aggregates, there are no additional restrictions on the Aggregate aspect of the expected type.} A null_container_aggregate can be of any type with an Aggregate aspect.]
Modify 4.3.5(26/5): (3)
A container_element_association with a <> rather than an expression[, or with a key_choice that is a discrete_range,] is permitted only in an indexed aggregate.
Delete 4.3.5(38/5):
* for a named_container_aggregate without an iterated_element_association, the
number of key_expressions;
Modify 4.3.5(39/5):
* for a named_container_aggregate where {each}[every]
iterated_element_association{, if any,} contains a loop_parameter_specification, the total number of elements specified by all of the container_element_associations;
Delete 4.9(8.1/5): (4)
* an attribute_reference whose prefix denotes a non-generic entity that is not
declared in a generic unit, and whose attribute_designator is Nonblocking;
Also remove the AARM Note at 4.9(44.cc/5).
(1) We could look at the definition of every aspect and decide if additional wording is needed. But that will continue to be required with every new edition of the RM. We chose instead to have all aspects be operational unless specified otherwise.
(2) We wanted to make it clear that a null container aggregate can be of any type with an Aggregate aspect. But once we've done that, we've covered almost all of the cases, and it seems like the remaining cases are missing.
We could have had an additional rule that a named_container_aggregate with an iterator_specification shall have a type with Add_Named or Add_Unnamed (as an indexed aggregate is not allowed for such an iterator), but the additional rule doesn't change what is or is not allowed.
(3) For a discrete_range to be legal, the key type of the container type has to be discrete. But there is no problem describing the operation of such ranges, and indeed we have to do so anyway as the (dynamic semantics) wording is shared with indexed aggregates which do allow these.
The original author of container aggregates thinks that the restriction came from an early version that existed before indexed aggregates were added. That makes it vestigal, and it should be eliminated.
The Dynamic Semantics wording for the bulk of the implementation of container aggregates does not need a change for this relaxation, but the determination of the aggregate length wording in 4.3.5(38/5) does not make sense if some choices can be ranges. The wording in 4.3.5(39/5) works fine for this case, so we just delete 4.3.5(38/5) and add a parenthetical remark into 4.3.5(39/5) hopefully making it clear that it applies as well if there are no iterators at all.
(4) When the attribute was deleted, this rule should have been removed as well, but obviously was not.
@drepl
The expected type for a @fa{positional_container_aggregate} shall have an
Aggregate aspect that includes a specification for an Add_Unnamed
procedure or an Assign_Indexed procedure. The expected type for a
@fa{named_container_aggregate} that contains one or more
@fa{iterated_element_association}s with a @i{key_}@fa{expression} shall have an
Aggregate aspect that includes a specification for the Add_Named
procedure. The expected type for a @fa{named_container_aggregate} that
contains one or more @fa{key_choice_list}s shall have an Aggregate aspect
that includes a specification for the Add_Named or Assign_Indexed
procedure. A @fa{null_container_aggregate} can be of any type
with an Aggregate aspect.
@dby
The expected type for a @fa{positional_container_aggregate} shall have an
Aggregate aspect that includes a specification for an Add_Unnamed
procedure or an Assign_Indexed procedure. The expected type for a
@fa{named_container_aggregate} that contains one or more
@fa{iterated_element_association}s with a @i{key_}@fa{expression} shall have an
Aggregate aspect that includes a specification for the Add_Named
procedure. The expected type for a @fa{named_container_aggregate} that
contains one or more @fa{key_choice_list}s shall have an Aggregate aspect
that includes a specification for the Add_Named or Assign_Indexed
procedure. For other kinds of @fa{named_container_aggregate}s, there are no
additional restrictions on the Aggregate aspect of the expected type. A
@fa{null_container_aggregate} can be of any type with an Aggregate aspect.
@drepl
A @fa{container_element_association} with a <> rather than an @fa{expression},
or with a @fa{key_choice} that is a @fa{discrete_range}, is permitted only in
an indexed aggregate.
@dby
A @fa{container_element_association} with a <> rather than an @fa{expression}
is permitted only in an indexed aggregate.
@ddel
@xinbull{for a @fa{named_container_aggregate} without an
@fa{iterated_element_association}, the number of @i{key_}@fa{expression}s;}
@drepl
@xinbull{for a @fa{named_container_aggregate} where every
@fa{iterated_element_association} contains a @fa{loop_parameter_specification},
the total number of elements specified by all of the
@fa{container_element_association}s;}
@dby
@xinbull{for a @fa{named_container_aggregate} where each
@fa{iterated_element_association}, if any, contains a
@fa{loop_parameter_specification}, the total number of elements specified by
all of the @fa{container_element_association}s;}
@ddel
@xbullet{an @fa{attribute_reference} whose @fa{prefix} denotes a non-generic
entity that is not declared in a generic unit, and whose
@fa{attribute_designator} is Nonblocking;}
@drepl
Two kinds of aspects of entities can be specified: representation aspects and
operational aspects. Representation aspects affect how the types and other
entities of the language are to be mapped onto the underlying machine.
Operational aspects determine other properties of entities.
@dby
Two kinds of aspects of entities can be specified: representation aspects and
operational aspects. Representation aspects affect how the types and other
entities of the language are to be mapped onto the underlying machine.
Operational aspects determine other properties of entities. When
not specified otherwise, an aspect is defined to be an operational aspect.
(1) No ACATS test should be needed specifically for this rule, although additional tests might be needed for existing aspects if they were not previously identified as operational aspects.
(2) No ACATS test is needed, this is redundant wording.
(3) An ACATS C-Test should try a discrete range in an appropriate aggregate.
(4) Can't test a nonexistent attribute in any useful way.
From: Randy Brukardt [privately]
Sent: Monday, September 13, 2021 1:10 AM
When looking at the items to test, I noticed that the AARM says that we added
wording to allow the Nonblocking attribute to be static. Of course, we deleted
that attribute. But, indeed, the wording remains in 4.9.
I guess if someone invents their own Nonblocking attribute, it will be static
some of the time. ;-)
Another minor thing to fix.
****************************************************************
[Summary of a private e-mail exchange between Randy Brukardt and Tucker Taft
in November 2021.]
[Randy] 4.3.5(50/5) says that an indexed aggregate is evaluated like a named
aggregate. But the wording in 4.3.5(46/5) does not take into account the
case where a choice is a discrete_range (since that isn't allowed for
Add_Named aggregates).
[Tucker Reply #1]
Not sure what makes you say that a discrete_range isn't permitted for
Add_Named aggregates.
[Randy Reply #1]
4.3.5(26/5) says:
A container_element_association with a <> rather than an expression, or with
a key_choice that is a discrete_range, is permitted only in an indexed
aggregate.
An aggregate implemented with Add_Named is never an indexed aggregate. Hard
to get any clearer than that. :-)
[Tucker Reply #2]
That looks like an unnecessary restriction to me. As you mention below, we
allow iterated_component_associations, one choice of which is a
loop_parameter_specification, which can use a discrete_range. And we allow
a list of key_choices. So I can't quite imagine why, if we allow
[1|2|3 => X], we don't also allow [1..3 => X]. I did a little spelunking
into the history of this rule, and it turns out that before we invented (on
your request!) the notion of indexed aggregates, we only allowed:
key_expression | key_expression ... => expression
When we added indexed aggregates, it was clear we wanted to allow a
discrete_range. But for some reason I was reluctant to generalize them to
all container aggregates. But now I think I was just being overly
conservative. They make perfect sense for any case where the key type is
discrete. So I would change 4.3.5(26/5) to:
A container_element_association with a <> rather than an expression[, or
with a key_choice that is a discrete_range,] is permitted only in an
indexed aggregate.
[Tucker Reply #1]
They are legal the way I read the rules. In particular, the legality rule
in 4.3.5(27/5) seems to permit it so long as the discrete_range's type
matches that of the key type:
For an iterated_element_association without a key_expression, if [...] the
expected type of the aggregate specifies an Add_Named procedure in its
Aggregate aspect, then the type of the loop parameter of the
iterated_element_association shall be the same as the key type of the
aggregate.
[Randy Reply #2]
That *could* have been the model, and IMHO, I think in hindsight that it
*should* be the model, but 4.3.5(26/5) is crystal clear.
Additionally, there is a minor hole here: a loop_parameter_specification
can have a discrete_range, (legal if the key type of Add_Named is discrete
or there is a key expression). As such, there doesn't seem to be a ton of
reason to disallow a discrete_range as a key_choice (assuming the type is
OK). Maybe we should simply drop the part of 4.3.5(26/5) about the key_choice.
[Tucker Reply #2]
Great minds...
****************************************************************
From: Randy Brukardt
Sent: Tuesday, November 16, 2021 12:00 AM
I noticed today a problem with the solution for the third question of
AI22-0018-1: the wording of 4.3.5(38/5) doesn't make sense if discrete_ranges
are allowed in choices. I think the best solution to that is to delete that
bullet entirely and add a parenthetical remark to the next one to make it
clear that it also applies if there are no iterated_element_associations. I've
updated the AI accordingly and reposted it (and updating everything with it,
hopefully).
Apologies for any inconvenience.
****************************************************************
From: Tucker Taft
Sent: Tuesday, November 16, 2021 7:51 AM
Or you could replace:
... the number of key_expressions;
with
... the total number of elements specified by all of the key_choices;
****************************************************************