Version 1.4 of ai05s/ai05-0269-1.txt

Unformatted version of ai05s/ai05-0269-1.txt version 1.4
Other versions for file ai05s/ai05-0269-1.txt
!standard 3.2.4(0)          12-01-26 AI05-0269-1/04
!standard 3.5(56/2)
!standard 3.10.1(13)
!standard 4.1.5(0)
!standard 4.1.6(0)
!standard 4.5.2(27)
!standard 4.5.2(28)
!standard 4.5.2(30.2/2)
!standard 4.9(33)
!standard 13.3(65)
!standard 13.11(21)
!standard 13.11.3(5)
!standard 13.11.4(0)
!standard 13.13.2(26)
!standard A.16.1(0)
!standard A.17(19/2)
!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 B.1(1)
!standard B.1(51)
!standard B.3.3(1/2)
!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 of the Ada 2012 Standard.
!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".
(8) The term "invididual membership test" is used twice before it is defined, which is confusing and unnecessary. Add a separate definition for the term before it is used.
(9) It's not clear whether the first "designated type" talked about in 4.5.2(30.3/3) is that of the tested type or of the simple_expression. Clarify that.
(10) 4.9(32.5/3) talks about how the selecting_expression "is static and is not covered by" a discrete_choice_list. This doesn't make much sense, because a discrete_choice is defined to cover a value by 3.8.1(9) (not an expression). "Value" (of the selecting_expression) needs to be mentioned somehow.
(11) The introduction of 3.2.4 is the first place that aspects and aspect_specifications are mentioned in the Standard. We need a strong forward reference.
(12) 3.2.4(7/3) says "a static expression that does not raise any exception;", but an expression that could raise an exception is not static by 4.9(34/3), so the part about the exception is just noise.
(13) We shall not use "shall" in notes, so 3.10.1(13.1/3) should be fixed.
(14) There are too many expecteds in 4.1.5(5/3). Get rid of one of them.
(15) "All of such" should be "all such" in 4.1.6(3/3).
(16) 3.5(56.1/3) is confusing. Please clarify.
(17) The first sentence of A.16.1(16/3) ends abruptly. Please improve.
(18) In A.17(19/3), the second ""variable" should be plural.
(19) In Annex B, we usually say "the <something> aspect". The first two uses in B.1(1/3) say "aspect <something>" instead. Please change.
(20) It would be nice for a type to be given in the example of B.1(51/3).
(21) In B.3.3(1/3), "leaves no space" is really informal; "allocates no space" would be better.
(22) 13.13.2(26) says that the discriminants are written with "S'Write"; but S in this context is the discriminanted record type. This should be fixed.
(23) 13.11(21.5/3) says that "The Alignment parameter is at least D'Alignment ...". This allows passing 5 if D'Alignment is 4, and is generally weird.
!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} ...
(8) Add before 4.5.2(27/3):
An individual membership test is the membership test of a single membership_choice.
Remove the italics from 4.5.2(28/3).
(9) Modify 4.5.2(30.3/3): "...if the designated type {of the tested type} is tagged ..."
(10) Modify 4.9(32.5/3): "...whose /selecting_/expression is static and {whose value} is not covered by the corresponding discrete_choice_list..."
(11) Add to the end of 3.2.4(1/3): General rules for aspects and aspect_specifications are found in chapter 13 (13.1 and 13.3.1 respectively).
(12) Modify 3.2.4(7/3): "a static expression[ that does not raise any exception];"
(13) Modify 3.10.1(13.1/3): "...statement {cannot}[shall not] be of an...".
(14) Replace 4.1.5(5/3) by: "The expected type for the reference_object_name in a generalized_reference is any reference type."
(15) Modify 4.1.6(3/3): "... All [of] such functions ..."
(16) Replace 3.5(56.1/3) with:
An implementation may extend the Wide_Wide_Value, Wide_Value, and Value attributes of a character type to accept strings of the form "Hex_hhhhhhhh" (ignoring case) for any character (not just the ones for which Wide_Wide_Image would produce that form -- see 3.5.2), as well as three-character strings of the form "'X'", where X is any character, including non-graphic characters.
(17) Modify A.16.1(16/3):
In addition to the operations provided in package Directories.Hierarchical_File_Names, {the} operations in package Directories can be used {with hierarchical file names}. In particular, functions Full_Name, Base_Name, and Extension are {provide additional capabilities for}[usable with] hierarchical file names.
(18) Modify A.17(19/3): "...all existing environment variable{s}..."
(19) Change "Specifying aspect Import to..." to "Specifying the Import aspect to..." and similarly for Export in B.1(1/3).
(20) Replace the example B.1(51/3) with:
package Fortran_Library is function Sqrt (X : Float) return Float with Import => True, Convention => Fortran; type Matrix is array (Natural range <>, Natural range <>) of Float with Convention => Fortran; function Invert (X : Matrix) return Matrix with Import => True, Convention => Fortran; end Fortran_Library;
(21) Modify B.3.3(1/3): "...[leaves]{allocates} no space...".
(22) Modify 13.13.2(26):
"... S'Output first writes the discriminants (using [S'Write]{the Write attribute of the discriminant type} for each), and S'Input first reads the discriminants (using [S'Read]{the Read attribute of the discriminant type} for each)."
(23) Modify 13.11(21.5/3):
"... The Alignment parameter is {a nonzero integral multiple of}[at least] @i<D>'Alignment if @i<D> is a specific type, and otherwise is {a nonzero integral multiple}[at least] of the alignment of the specific type identified by the tag of the object being created. ..."
!discussion
For (23), we copy the wording of 13.3(26.3/2).
!corrigendum 3.2.4(0)
Insert new clause:
[A placeholder to cause a conflict; the real wording is found in the conflict file.]
!corrigendum 3.5(56/2)
Insert after the paragraph:
An implementation may extend the Wide_Wide_Value, Wide_Value, Value, Wide_Wide_Image, Wide_Image, and Image attributes of a floating point type to support special values such as infinities and NaNs.
the new paragraphs:
An implementation may extend the Wide_Wide_Value, Wide_Value, and Value attributes of a character type to accept strings of the form "Hex_hhhhhhhh" (ignoring case) for any character (not just the ones for which Wide_Wide_Image would produce that form — see 3.5.2), as well as three-character strings of the form "'X'", where X is any character, including non-graphic characters.
!corrigendum 3.10.1(13)
Insert after the paragraph:
85 Within a declarative_part, an incomplete_type_declaration and a corresponding full_type_declaration cannot be separated by an intervening body. This is because a type has to be completely defined before it is frozen, and a body freezes all types declared prior to it in the same declarative_part (see 13.14).
the new paragraph:
86 A name that denotes an object of an incomplete view is defined to be of a limited type. Hence, the target of an assignment statement cannot be of an incomplete view.
!corrigendum 4.1.5(0)
Insert new clause:
[A placeholder to cause a conflict; the real wording is found in the conflict file.]
!corrigendum 4.1.6(0)
Insert new clause:
[A placeholder to cause a conflict; the real wording is found in the conflict file.]
!corrigendum 4.5.2(27)
Insert before the paragraph:
For the evaluation of a membership test using in whose membership_choice_list has a single membership_choice, the simple_expression and the membership_choice are evaluated in an arbitrary order; the result is the result of the individual membership test for the membership_choice.
the new paragraph:
An individual membership test is the membership test of a single membership_choice.
!corrigendum 4.5.2(28)
Replace the paragraph:
An individual membership test yields the result True if:
by:
An individual membership test yields the result True if:
!corrigendum 4.5.2(30.2/2)
Replace the paragraph:
by:
!corrigendum 4.9(33)
Replace the paragraph:
A static expression is evaluated at compile time except when it is part of the right operand of a static short-circuit control form whose value is determined by its left operand. This evaluation is performed exactly, without performing Overflow_Checks. For a static expression that is evaluated:
by:
A static expression is evaluated at compile time except when it is statically unevaluated. The compile-time evaluation of a static expression is performed exactly, without performing Overflow_Checks. For a static expression that is evaluated:
!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(21)
@Comment{This is a partial change, the entire change is found in the conflict file.}
Insert after the paragraph:
If Storage_Pool is specified for an access type, then if Allocate can satisfy the request, it should allocate a contiguous block of memory, and return the address of the first storage element in Storage_Address. The block should contain Size_In_Storage_Elements storage elements, and should be aligned according to Alignment. The allocated storage should not be used for any other purpose while the pool element remains in existence. If the request cannot be satisfied, then Allocate should propagate an exception (such as Storage_Error). If Allocate behaves in any other manner, then the program execution is erroneous.
the new paragraphs:
Implementation Requirements
For each of the calls of Allocate described above, P (equivalent to T'Storage_Pool) is passed as the Pool parameter. The Size_In_Storage_Elements parameter indicates the number of storage elements to be allocated, and is no more than D'Max_Size_In_Storage_Elements, where D is the designated subtype of T. The Alignment parameter is a nonzero integral multiple of D'Alignment if D is a specific type, and otherwise is a nonzero integral multiple of the alignment of the specific type identified by the tag of the object being created. The Alignment parameter is no more than D'Max_Alignment_For_Allocation. The result returned in the Storage_Address parameter is used as the address of the allocated storage, which is a contiguous block of memory of Size_In_Storage_Elements storage elements. Any exception propagated by Allocate is propagated by the construct that contained the call.
!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 13.13.2(26)
Replace the paragraph:
by:
!corrigendum A.16.1(0)
Insert new clause:
[A placeholder to cause a conflict; the real wording is found in the conflict file.]
!corrigendum A.17(19/2)
Replace the paragraph:
If the external execution environment supports environment variables, then Clear deletes all existing environment variable with the given name. Otherwise Program_Error is propagated.
by:
If the external execution environment supports environment variables, then Clear deletes all existing environment variables with the given name. Otherwise, Program_Error is propagated.
!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 B.1(1)
Replace the paragraph:
A pragma Import is used to import an entity defined in a foreign language into an Ada program, thus allowing a foreign-language subprogram to be called from Ada, or a foreign-language variable to be accessed from Ada. In contrast, a pragma Export is used to export an Ada entity to a foreign language, thus allowing an Ada subprogram to be called from a foreign language, or an Ada object to be accessed from a foreign language. The pragmas Import and Export are intended primarily for objects and subprograms, although implementations are allowed to support other entities.
by:
An interfacing aspect is a representation aspect that is one of the aspects Import, Export, Link_Name, External_Name, or Convention.
Specifying the Import aspect to have the value True is used to import an entity defined in a foreign language into an Ada program, thus allowing a foreign-language subprogram to be called from Ada, or a foreign-language variable to be accessed from Ada. In contrast, specifying the Export aspect to have the value True is used to export an Ada entity to a foreign language, thus allowing an Ada subprogram to be called from a foreign language, or an Ada object to be accessed from a foreign language. The Import and Export aspects are intended primarily for objects and subprograms, although implementations are allowed to support other entities. The Link_Name and External_Name aspects are used to specify the link name and external name, respectively, to be used to identify imported or exported entities in the external environment.
!corrigendum B.1(51)
Replace the paragraph:
package Fortran_Library is function Sqrt (X : Float) return Float; function Exp (X : Float) return Float; private pragma Import(Fortran, Sqrt); pragma Import(Fortran, Exp); end Fortran_Library;
by:
package Fortran_Library is function Sqrt (X : Float) return Float with Import => True, Convention => Fortran; type Matrix is array (Natural range <>, Natural range <>) of Float with Convention => Fortran; function Invert (M : Matrix) return Matrix with Import => True, Convention => Fortran; end Fortran_Library;
!corrigendum B.3.3(1/2)
Replace the paragraph:
A pragma Unchecked_Union specifies an interface correspondence between a given discriminated type and some C union. The pragma specifies that the associated type shall be given a representation that leaves no space for its discriminant(s).
by:
Specifying aspect Unchecked_Union to have the value True defines an interface correspondence between a given discriminated type and some C union. The aspect requires that the associated type shall be given a representation that allocates no space for its discriminant(s).
!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: Steve Baird
Sent: Friday, March 11, 2011  7:06 PM

[This message was misplaced which is why it is getting handled in this AI; only the
relevant part is included here.]

While looking at this, I did notice a minor wording issue.

In 13.13.2(26), the parenthesized wording eems wrong:

    If T has discriminants without defaults, S'Output first writes the
    discriminants (using S'Write for each), and S'Input first reads the
    discriminants (using S'Read for each).

S is a discriminated subtype. We are using S'Write and S'Read to write/read single
discriminant values? Probably "using S'Write" should be replaced with something like "using
the Write attribute of each dicriminant type", and similarly for Read.

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

From: Bob Duff
Sent: Wednesday, September 15, 2010  4:39 PM

[This thread was unintentionally ignored and just now has been rediscovered,
which is why it is getting handled in this AI - Editor.]

AI05-0193-1: Alignment of allocators says:

    The Alignment parameter is at least D'Alignment if D is a specific type,
    and otherwise is at least the alignment of the specific type identified by
    the tag of the object being created. The Alignment parameter is no more
    than D'Max_Alignment_For_Allocation.

Shouldn't it say it's "equal to or stricter than D'Alignment"?
That is, equal to D'Alignment, or some positive integer multiple thereof.

Because if D'Alignment is 4, you don't want to pass Alignment => 5 to Allocate.
4, 8, or 16 should be OK. 12 is weird, but still OK, I guess.

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

From: Robert Dewar
Sent: Wednesday, September 15, 2010  4:41 PM

Only powers of 2 make sense for alignments anyway, so in practice greater/less
than mean the same as multiple/factor

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

From: Tucker Taft
Sent: Wednesday, September 15, 2010  5:05 PM

I agree "stricter" is more correct.
Do we use that term elsewhere?

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

From: Bob Duff
Sent: Wednesday, September 15, 2010  5:39 PM

> I agree "stricter" is more correct.
> Do we use that term elsewhere?

Only in the AARM, as far as I know.

I don't think we need to have a formal definition of "stricter" in order to use
it in the RM. It's clear what it means.

Or we can just leave it alone, and trust implementers to never pass Alignment=>5
or the like.

Re: Robert's comment: I would have been happy with a rule saying Alignment must
be a power of 2. I can't imagine any hardware (past, present, or future) where
anything else would make sense. I'd be interested in hearing of
counter-examples, if such exist[ed]!

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

From: Robert Dewar
Sent: Wednesday, September 15, 2010  6:11 PM

Certainly GNAT requires alignments to be a power of 2

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

From: Tucker Taft
Sent: Wednesday, September 15, 2010  6:09 PM

> I don't think we need to have a formal definition of "stricter" in
> order to use it in the RM.
> It's clear what it means. ...

What I was really asking was how do we require that one alignment be stricter
than another alignment in other places in the manual.  I just looked in the
section on the 'Alignment attribute, and we always talk in terms of one
alignment being a multiple of another alignment.  So I think we should use that
terminology here, rather than "greater" or "stricter".

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

From: Bob Duff
Sent: Wednesday, September 15, 2010  6:31 PM

OK, that makes sense.

[Randy will no doubt include this in the appendix of the AI in a way that makes
the referent of "that" in "that makes sense" unclear.  Sigh.]

[Editor's note: I did my best to follow his instructions. :-) If you the reader
are really confused, the preceeding message is the referent.]

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

From: Randy Brukardt
Sent: Monday, September 27, 2010  5:59 PM

Forget my filing system: my new phone just showed "OK, that makes sense"
with all of the quoted stuff eliminated. So I didn't find out what you meant
until I looked at it here in the office. Probably best to write a few more words
(but that's not fun when answering from a phone).

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

From: Bob Duff
Sent: Monday, September 27, 2010  6:19 PM

Reading e-mail on a phone is something I would never consider doing.
I realize that makes me a luddite.  ;-)

But seriously, I don't think you should be vigorously trying to keep the
!appendix sections small.  Over-quoting is a sin, but underquoting is a worse
sin.  I really find it hard to follow the conversation when I can't tell what
someone is replying to.

And I was deliberately yanking your chain when I wrote just "OK, that makes
sense.", which is incomprehensible without context.  ;-)

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

From: Randy Brukardt
Sent: Friday, January 27, 2012  1:53 AM

A couple of weeks ago, I responded to one of Steve's comments thusly:

> > 13.11(21.5/3) says
> >    The Alignment parameter is at least D'Alignment if D is a
> > specific type, ...
> >
> > It does seem odd that if D'Alignment is 4, then this would allow
> > passing in a value of 5.
> >
> > We may have already talked about this one and decided to ignore it.
>
> I vaguely remember such a discussion, but it doesn't seem to appear in
> the filed e-mail (or we decided to ignore it).
>
> It doesn't seem too critical; it sounds hard to nail this down
> perfectly. (I can't think of a reason to support an alignment of, say
> 6, but I wouldn't be surprised of someone had a reason on some unusual
> machine. So requiring only powers-of-two along wouldn't seem
> appropriate to me.)

I just ran across the old e-mail discussion (from September 2010!). Tucker
suggested using "multiple" as that is what 13.3 uses when comparing to
alignments. (Actually, the wording is "nonzero integral multiple".) It seems
that your editor was supposed to make this change, but it got lost in a blizzard
of mail on other topics.

So the wording should be:

The Alignment parameter is a nonzero integral multiple of D'Alignment if D is a
specific type, and otherwise is a nonzero integral multiple the alignment of the
specific type identified by the tag of the object being created.

Please speak up if you (or anyone) disagrees for some reason. (It's been a year
and a half; everyone should have changed their minds by now... :-)

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

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