CVS difference for ai05s/ai05-0269-1.txt
--- ai05s/ai05-0269-1.txt 2012/01/20 03:34:28 1.3
+++ ai05s/ai05-0269-1.txt 2012/01/27 23:23:12 1.4
@@ -1,11 +1,27 @@
-!standard 13.3(65) 12-01-12 AI05-0269-1/02
+!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
@@ -17,7 +33,7 @@
!subject Editorial comments on Draft 14
!summary
-Handle editorial comments on Draft 14
+Handle editorial comments on Draft 14 of the Ada 2012 Standard.
!proposal
@@ -44,6 +60,50 @@
(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).
@@ -59,7 +119,7 @@
(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.
+it defines} [used to define] the default pool for access types within an instance.
(6) Modify 13.12.1(2.1/3):
@@ -72,16 +132,207 @@
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)
+
+@dinsc
+[A placeholder to cause a conflict; the real wording is found in the conflict
+file.]
+
+!corrigendum 3.5(56/2)
+
+@dinsa
+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.
+@dinss
+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 @emdash
+see 3.5.2), as well as three-character strings of the form "'@i<X>'", where @i<X> is
+any character, including non-graphic characters.
+
+!corrigendum 3.10.1(13)
+
+@dinsa
+@xindent<@s9<85 Within a @fa<declarative_part>, an @fa<incomplete_type_declaration>
+and a corresponding @fa<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 @fa<declarative_part> (see 13.14).>>
+@dinst
+@xindent<@s9<86 A @fa<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)
+
+@dinsc
+[A placeholder to cause a conflict; the real wording is found in the conflict
+file.]
+!corrigendum 4.1.6(0)
+@dinsc
+[A placeholder to cause a conflict; the real wording is found in the conflict
+file.]
+
+!corrigendum 4.5.2(27)
+
+@dinsb
+For the evaluation of a membership test using @b<in> whose @fa<membership_choice_list>
+has a single @fa<membership_choice>, the @fa<simple_expression> and the @fa<membership_choice>
+are evaluated in an arbitrary order; the result is the result of the individual
+membership test for the @fa<membership_choice>.
+@dinst
+An @i<individual membership test> is the membership test of a single @fa<membership_choice>.
+
+!corrigendum 4.5.2(28)
+
+@drepl
+An @i<individual membership test> yields the result True if:
+@dby
+An individual membership test yields the result True if:
+
+!corrigendum 4.5.2(30.2/2)
+
+@drepl
+@xbullet<if the tested type is an access type and the named subtype excludes null,
+the value of the @fa<simple_expression> is not null.>
+@dby
+@xbullet<if the tested type is an access type and the named subtype excludes null,
+the value of the @fa<simple_expression> is not null;>
+
+@xbullet<if the tested type is a general access-to-object type, the type of the
+@fa<simple_expression> is convertible to the tested type and its
+accessibility level is no deeper than that of the tested type;
+further, if the designated type of the tested type is tagged and the
+@fa<simple_expression> is non-null, the tag of the object designated by the value of the
+@fa<simple_expression> is covered by the designated type of the tested type.>
+
+!corrigendum 4.9(33)
+
+@drepl
+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:
+@dby
+@xbullet<a @i<dependent_>@fa<expression> of a @fa<case_expression> whose
+@i<selecting_>@fa<expression> is static and whose value is not covered by the
+corresponding @fa<discrete_choice_list>; or>
+
+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)
@ddel
[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.}
+@dinsa
+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.
+@dinss
+@s8<@i<Implementation Requirements>>
+
+For each of the calls of Allocate described above, @i<P> (equivalent to @i<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
+@i<D>'Max_Size_In_Storage_Elements, where @i<D> is the designated subtype of @i<T>.
+The Alignment parameter is a nonzero integral multiple of @i<D>'Alignment if @i<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
+@i<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)
@dinsc
@@ -101,6 +352,38 @@
instances of language-defined generic packages.
Such identifiers can arise as follows:>
+!corrigendum 13.13.2(26)
+
+@drepl
+@xbullet<If T is an array type, S'Output first writes the bounds, and S'Input first
+reads the bounds. 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).>
+@dby
+@xbullet<If T is an array type, S'Output first writes the bounds, and S'Input first
+reads the bounds. If T has discriminants without defaults, S'Output first writes the
+discriminants (using the Write attribute of the discriminant type for each), and
+S'Input first reads the discriminants (using the Read attribute of the discriminant
+type for each).>
+
+!corrigendum A.16.1(0)
+
+@dinsc
+[A placeholder to cause a conflict; the real wording is found in the conflict
+file.]
+
+!corrigendum A.17(19/2)
+
+@drepl
+If the external execution environment supports environment variables, then Clear deletes
+all existing environment variable with the given name. Otherwise Program_Error
+is propagated.
+
+@dby
+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)
@dinsc
@@ -131,6 +414,65 @@
[A placeholder to cause a conflict; the real wording is found in the conflict
file.]
+!corrigendum B.1(1)
+
+@drepl
+A @fa<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 @fa<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 @fa<pragma>s
+Import and Export are intended primarily for objects and subprograms, although implementations
+are allowed to support other entities.
+@dby
+An @i<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)
+
+@drepl
+@xcode<@b<package> Fortran_Library @b<is>
+ @b<function> Sqrt (X : Float) @b<return> Float;
+ @b<function> Exp (X : Float) @b<return> Float;
+@b<private>
+ @b<pragma> Import(Fortran, Sqrt);
+ @b<pragma> Import(Fortran, Exp);
+@b<end> Fortran_Library;>
+@dby
+@xcode<@b<package> Fortran_Library @b<is>
+ @b<function> Sqrt (X : Float) @b<return> Float
+ @b<with> Import =@> True, Convention =@> Fortran;
+ @b<type> Matrix @b<is array> (Natural @b<range> <@>, Natural @b<range> <@>) @b<of> Float
+ @b<with> Convention =@> Fortran;
+ @b<function> Invert (M : Matrix) @b<return> Matrix
+ @b<with> Import =@> True, Convention =@> Fortran;
+@b<end> Fortran_Library;>
+
+!corrigendum B.3.3(1/2)
+
+@drepl
+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).
+@dby
+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)
@dinsc
@@ -138,8 +480,6 @@
file.]
-
-
!ACATS Test
None needed.
@@ -150,6 +490,185 @@
!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
@@ -183,18 +702,18 @@
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
+> 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
+> 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
@@ -268,19 +787,19 @@
Sent: Friday, January 13, 2012 1:22 AM
...
-> Is this a roundabout way of saying that this aspect may be
+> 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.
+> 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
@@ -294,7 +813,7 @@
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.
+an instance.
****************************************************************
Questions? Ask the ACAA Technical Agent