Version 1.1 of ai22s/ai22-0018-1.txt

Unformatted version of ai22s/ai22-0018-1.txt version 1.1
Other versions for file ai22s/ai22-0018-1.txt

!standard 4.3.5(24/5)          21-11-12 AI22-0018-1/01
!standard 4.3.5(26/5)
!standard 4.9(8.1/5)
!standard 13.1(0.1/3)
!class binding interpretation 21-11-12
!status work item 21-11-12
!status received 21-11-12
!priority Low
!difficulty Easy
!qualifier Omission
!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 (for instance, Preelaborable_Initialization) do not identify which class they are. 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.
(4) Drop a rule about a nonexistent attribute.
Modify 13.1(0.1/3):
[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):
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):
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.9(8.1/5):
* 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(
(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 a 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 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.
(4) When the attribute was deleted, this rule should have been removed as well, but obviously was not.
!ACATS test
(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 
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 
[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... 


Questions? Ask the ACAA Technical Agent