Version 1.3 of ai05s/ai05-0269-1.txt
!standard 13.3(65) 12-01-12 AI05-0269-1/02
!standard 13.11.3(5)
!standard 13.11.4(0)
!standard A.18.18(0)
!standard A.18.21(0)
!standard A.18.22(0)
!standard A.18.23(0)
!standard A.18.24(0)
!standard D.16.1(0)
!class Amendment 11-11-09
!status Amendment 2012 12-01-12
!status work item 11-11-09
!status received 11-07-20
!priority Low
!difficulty Easy
!qualifier Error
!subject Editorial comments on Draft 14
!summary
Handle editorial comments on Draft 14
!proposal
(1) Drop Pragma Preelaborate from D.16.1(3/3) (the package depends on Ada.Real_Time,
which is not preelaborated.
(2) The Implementation Advice for bounded maps and sets ought to include the kind,
so the M.3 summary does not look repetitive.
(3) We should always use "holder" as an adjective; using "holder container" if no other
option exists. There is only one element in a holder, so use "the element" instead of
"elements".
(4) There is no type named "Root_Subpool_Type", this should be fixed.
(5) 13.11.3(5/3) does not tell us where the aspect is allowed.
(6) The list of packages for 13.12.1(2.1/3) includes Interfaces.C.Pointers, which is
a generic package. But the wording does not strictly apply to it (a generic package
is not a package, and a instance of it is not a language-defined package). This should
be fixed.
(7) "The aspect Storage_Size" in 13.3(65.2/3) is inconsistent with the following rules
which use "The Storage_Size aspect".
!wording
(1) Remove pragma Preelaborate from D.16.1(3/3).
(2) Add "hashed" to A.18.21(21/3), "ordered" to A.18.22(18/3), "hashed" to A.18.23(20/3),
and "ordered to A.18.24(17/3), in front of "map" or "set".
(3) Change "holder" to "holder container" in A.18.18(70,72,74/3). Change "elements" to
"the element" in A.18.18(73/3).
(4) Replace "Root_Subpool_Type" with "Root_Subpool" in 13.11.4(19/3).
(5) Modify 13.11.3(5/3):
The language-defined aspect Default_Storage_Pool may be {specified for a generic instance;
it defines} [used to define] the default pool for access types within an instance.
(6) Modify 13.12.1(2.1/3):
There are no usage names that denote declarations with
implementation-defined identifiers that occur within language-defined
packages {or instances of language-defined generic packages}.
(7) Modify 13.3(65.2/3):
Storage_Size
The [aspect] Storage_Size {aspect} ...
!discussion
!corrigendum 13.3(65)
Delete the paragraph:
[A placeholder to cause a conflict; the real wording is found in the conflict
file.]
!corrigendum 13.11.4(0)
Insert new clause:
[A placeholder to cause a conflict; the real wording is found in the conflict
file.]
!corrigendum 13.12.1(2/2)
Insert after the paragraph:
- No_Implementation_Attributes
-
There are no implementation-defined attributes. This restriction applies only
to the current compilation or environment, not the entire partition.
the new paragraphs:
- No_Implementation_Identifiers
-
There are no usage names that denote declarations with
implementation-defined identifiers that occur within language-defined packages or
instances of language-defined generic packages.
Such identifiers can arise as follows:
!corrigendum A.18.18(0)
Insert new clause:
[A placeholder to cause a conflict; the real wording is found in the conflict
file.]
!corrigendum A.18.21(0)
Insert new clause:
[A placeholder to cause a conflict; the real wording is found in the conflict
file.]
!corrigendum A.18.22(0)
Insert new clause:
[A placeholder to cause a conflict; the real wording is found in the conflict
file.]
!corrigendum A.18.23(0)
Insert new clause:
[A placeholder to cause a conflict; the real wording is found in the conflict
file.]
!corrigendum A.18.24(0)
Insert new clause:
[A placeholder to cause a conflict; the real wording is found in the conflict
file.]
!corrigendum D.16.1(0)
Insert new clause:
[A placeholder to cause a conflict; the real wording is found in the conflict
file.]
!ACATS Test
None needed.
!ASIS
No change needed.
!appendix
From: Alan Burns
Sent: Monday, September 19, 2011 4:51 AM
We have just held IRTAW - lots of interesting stuff for post Ada2012!
But a couple of 'editorial' issues were noted with regard to D.16.1
package System.Multiprocessors.Dispatching_Domain has pragma Preelaborate. But it also
withs Ada.Real-Time that does not have this pragma. This seems to be wrong.
... [Rest omitted here, in AI05-0278-1.]
****************************************************************
From: Brad Moore
Sent: Wednesday, December 28, 2011 10:29 AM
[Part of a larger review... - Editor]
A.18.18 (73.a.1/3) Delete this paragraph, it is almost identical to the preceding
paragraph, and the 'Implementation Advice' tag is also redundant, since it falls
under the 'Implementation Advice' section.
...
If the preceding paragraphs are necessary, then there is a consistency problem, because
some of the containers do not have these redundant paragraphs.
****************************************************************
From: Randy Brukardt
Sent: Friday, December 30, 2011 11:38 PM
> A.18.18 (73.a.1/3) Delete this paragraph, it is almost identical to
> the preceding paragraph, and the 'Implementation Advice' tag is also
> redundant, since it falls under the 'Implementation Advice' section.
This is the "marker" note for the what becomes the contents of the Implementation
Advice annex (which is automatically generated from these notes). We could consider
suppressing these globally (so they aren't shown at all), but doing so would change
the paragraph numbers of some AARM notes silently, so that would not be a great idea.
...
> If the preceding paragraphs are necessary, then there is a consistency
> problem, because some of the containers do not have these redundant
> paragraphs.
Anything that doesn't have these paragraphs won't show up in the Annex (M.3), which would
be a fairly serious bug. There should be one after every implementation advice (or some
other note stating that we don't want an annex entry, there is a couple of cases of that).
I can't find any missing ones on a quicky random check. If you can, please tell me so
that I can fix them somehow.
****************************************************************
From: Brad Moore
Sent: Saturday, December 31, 2011 10:22 AM
The inconsistent containers are ;
A.18.22 The Generic Package Containers.Bounded_Ordered_Maps
<cid:part1.08030602.04050506@shaw.ca>
A.18.24 The Generic Package Containers.Bounded_Ordered_Sets
<cid:part2.01030905.05000005@shaw.ca>
****************************************************************
From: Randy Brukardt
Sent: Saturday, December 31, 2011 5:25 PM
Ah, I see that's intentional, because the wording of the Implementation Advice is
identical to the hashed versions. It would look insane to repeat that wording twice
in a row in the annex.
There should have been a comment in the code (rather than just in the source, where
there is one), so you could see why it is omitted.
Arguably, omitting these is a bad idea because the section reference is missed in the
annex. In that case, we need to change the (normative) wording of all four sets of this
advice to add "ordered" and "hashed" appropriately. Should we do that? What do you think?
****************************************************************
From: Brad Moore
Sent: Tuesday, January 3, 2012 12:22 PM
Definitely not a high priority issue, but if it's not too much trouble, I think it
would be good to make the changes in the name of consistency, otherwise it looks like
an omission.
****************************************************************
From: Steve Baird
Sent: Monday, January 9, 2012 3:43 PM
[Part of a larger review... - Editor]
Oh dear. I read 13.11.3 and became very confused. It isn't at all clear for which
entities the Default_Storage_Pool aspect may be specified.
5/3 says
The language-defined aspect Default_Storage_Pool may be used to define
the default pool for access types within an instance.
Is this a roundabout way of saying that this aspect may be specified for an instance?
It reads like non-normative introductory text. More precise wording is definitely needed,
especially when we are doing non-intuitive things like allowing it to be specified via
an aspect definition clause for an instance, but only via a pragma for a generic.
Or something like that. I can't tell.
Did we lose a paragraph or something?
****************************************************************
From: Randy Brukardt
Sent: Friday, January 13, 2012 1:22 AM
...
> Is this a roundabout way of saying that this aspect may be
> specified for an instance?
Yes (I think). The AARM notes explain the intended model, but I agree that the
normative wording ought to match.
> It reads like non-normative introductory text.
> More precise wording is definitely needed, especially when we
> are doing non-intuitive things like allowing it to be
> specified via an aspect definition clause for an instance,
> but only via a pragma for a generic. Or something like that.
> I can't tell.
>
> Did we lose a paragraph or something?
No, that's the wording in the original AI. So it is more that the text was
never there.
I don't think much additional is actually needed, add a second sentence:
"The aspect can be specified for a generic instance".
Or maybe it is better to just change the first sentence:
The language-defined aspect Default_Storage_Pool may be {specified for a generic
instance; it defines} [used to define] the default pool for access types within
an instance.
****************************************************************
Questions? Ask the ACAA Technical Agent