CVS difference for ai05s/ai05-0190-1.txt
--- ai05s/ai05-0190-1.txt 2011/04/30 07:28:36 1.16
+++ ai05s/ai05-0190-1.txt 2011/05/19 04:48:21 1.17
@@ -1,7 +1,8 @@
-!standard 13.11.3(0) 11-04-14 AI05-0190-1/11
+!standard 13.11.3(0) 11-05-18 AI05-0190-1/12
!standard 7.6.1(11/3)
!standard H.4(8.1/3)
!class amendment 09-11-03
+!status ARG Approved (by Letter Ballot) 9-1-1 11-05-16
!status work item 09-11-03
!status received 09-11-03
!priority Low
@@ -20,7 +21,7 @@
types, but few used for allocation. Another example is an embedded system for
which it is inappropriate to rely on the implementation-provided pools.
-This can be done by appplying "Storage_Size use 0" to all types that should not
+This can be done by applying "Storage_Size use 0" to all types that should not
have allocators, and explicitly specifying a Storage_Pool for the few others.
But this is error prone; one might forget the "Storage_Size use 0".
@@ -105,7 +106,7 @@
shall be null, and it defines the "default pool" to be null within all
applicable compilation units (see 10.1.5), except within the immediate scope of
another pragma Default_Storage_Pool. Otherwise, Redundant[the pragma occurs
-immediately within a sequence of declarations], and it defines the default pool
+immediately within a sequence of declarations, and] it defines the default pool
within the immediate scope of the pragma to be either null or the pool denoted
by the *storage_pool*_name, except within the immediate scope of a later pragma
Default_Storage_Pool. Redundant[Thus, an inner pragma overrides an outer one.]
@@ -141,8 +142,8 @@
If the default pool is nonnull, the Storage_Pool attribute is that
pool.
- Redundant[Otherwise, there is no default pool; the Storage_Pool attribute
- is implementation defined.]
+ Redundant[Otherwise, there is no default pool; the standard storage
+ pool is used for the type as described in 13.11.]
The language-defined aspect Default_Storage_Pool may be used to define the
default pool for access types within an instance. The expected type for the
@@ -159,9 +160,9 @@
coextensions. This matches the required finalization point for coextensions.
The default storage pool for an allocator that occurs within an instance of a
-generic is defined by the Default_Storage_Pool pragma that applied to the
-generic, or by the Default_Storage_Pool aspect of the instantiation; the
-Default_Storage_Pool pragma that applies to the instantiation is irrelevant.
+generic is defined by the Default_Storage_Pool aspect of the instantiation (if
+specified), or by the Default_Storage_Pool pragma that applied to the generic;
+the Default_Storage_Pool pragma that applies to the instantiation is irrelevant.
It is possible to specify the Default_Storage_Pool aspect for an instantiation
such that allocations will fail. For example, the generic unit might be
@@ -225,7 +226,7 @@
The wording change to 7.6.1(11/3) is necessary as the AI05-0051-1 wording assumed
that anonymous access types could not use a user storage pool. Since that's no
longer true, the laissez faire finalization cannot work. As a practical matter,
-it never could have worked (it is all to easy to write code with such dependencies,
+it never could have worked (it is all too easy to write code with such dependencies,
see the mail of January 27, 2011 in the !appendix for some examples).
In addition, the rules (both the Ada 2005 and the AI05-0051-1 version) does not
@@ -3458,7 +3459,7 @@
From: John Barnes
Sent: Thursday, April 07, 2011 5:26 AM
-!problem
+!problem
line 4 is is => it is
@@ -3502,3 +3503,340 @@
check that I didn't miss something.
****************************************************************
+
+From: Tucker Taft
+Sent: Monday, May 2, 2011 9:44 PM
+
+[Appropriate part of a large message - Editor.]
+
+AI05-0190-1/11 Global storage pool controls
+ [Uses new term from AI05-0243-1 to fix finalization issues; pool pragmas.]
+ Approve __X____ Disapprove ______ Abstain _______
+ Comments:
+ Should we move pragma Controlled to the obsolescent Annex?
+
+ Normally, we try to make the redundant brackets enclose a phrase
+ which could be omitted. In this, we probably need to enclose the
+ word ", and" as well: "... Otherwise, Redundant[the pragma occurs
+ immediately within a sequence of declarations], and it defines
+ the ..."
+
+ This doesn't make sense to me:
+ A pragma Default_Storage_Pool shall not be used as a configuration pragma
+ within the immediate scope of another such pragma.
+ Configuration pragmas appear outside of any scope, at the beginning
+ of a "compilation." Perhaps we mean to say that a Default_Storage_Pool
+ configuration pragma is not permitted if it applies to a compilation
+ unit which is within the immediate scope of another Default_Storage_Pool
+ pragma.
+
+ This is confusing to me:
+ Redundant[Otherwise, there is no default pool; the Storage_Pool attribute
+ is implementation defined.]
+ Can we just leave out this case completely? It seems to be implying that
+ this is a special case, when in fact this is the normal case. If we feel we
+ must say something, I would prefer we just send them off to 13.11 rather
+ than saying that it is "implementation defined." In the Intro to 13.11,
+ the RM says: "By default, the implementation chooses a standard storage pool
+ for each access-to-object type."
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, May 2, 2011 10:32 PM
+
+[Appropriate part of a larger message - Editor.]
+
+> AI05-0190-1/11 Global storage pool controls
+> [Uses new term from AI05-0243-1 to fix finalization issues; pool pragmas.]
+> Approve __X____ Disapprove ______ Abstain _______
+> Comments:
+> Should we move pragma Controlled to the obsolescent Annex?
+
+AI05-0229-1 does that.
+
+...
+> This doesn't make sense to me:
+> A pragma Default_Storage_Pool shall not be used as a configuration pragma
+> within the immediate scope of another such pragma.
+> Configuration pragmas appear outside of any scope, at the beginning
+> of a "compilation." Perhaps we mean to say that a Default_Storage_Pool
+> configuration pragma is not permitted if it applies to a compilation
+> unit which is within the immediate scope of another Default_Storage_Pool
+> pragma.
+
+I have no idea. Bob??
+
+> This is confusing to me:
+> Redundant[Otherwise, there is no default pool; the Storage_Pool attribute
+> is implementation defined.]
+> Can we just leave out this case completely? It seems to be implying that
+> this is a special case, when in fact this is the normal case. If we feel we
+> must say something, I would prefer we just send them off to 13.11 rather
+> than saying that it is "implementation defined." In the Intro to 13.11,
+> the RM says: "By default, the implementation chooses a standard storage pool
+> for each access-to-object type."
+
+Probably a reference to 13.11 would be best.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Sunday, May 15, 2011 11:32 AM
+
+[Appropriate part of a larger message - Editor.]
+
+AI05-0190-1/11 Global storage pool controls
+ [Uses new term from AI05-0243-1 to fix finalization issues; pool pragmas.]
+ Approve ______ Disapprove __X____ Abstain _______
+
+================
+
+comment: It is regrettable in this day and age of multicore that we stuck to
+strict sequentiality in the first sentence of 7.6.1(11), since we were already
+changing the words. I approve of the finalization wording only because the old
+wording was much worse and because it is late in the game.
+
+I seriously disagree with the writeup of the Default_Storage_Pool pragma (but
+not with the general intent of such a pragma.):
+
+> The default storage pool for an allocator that occurs within an
+> instance of a generic is defined by the Default_Storage_Pool pragma
+> that applied to the generic, or by the Default_Storage_Pool aspect of
+> the instantiation;
+
+add: {and the user shall toss a coin to guess which it is; he may also query the
+oracle of Delphi or call the language designers at 0-800-... (49c/minute)} i.e.,
+I strongly disagree if this is really the intended un-semantics.
+
+> the Default_Storage_Pool pragma that applies to the instantiation is
+> irrelevant.
+
+surprising: what happened to the notion that aspect pragmas do specify aspects?
+
+
+****************************************************************
+
+From: Brad Moore
+Sent: Sunday, May 15, 2011 2:52 PM
+
+[Appropriate part of a larger message - Editor.]
+
+> AI05-0190-1/11 Global storage pool controls
+> [Uses new term from AI05-0234-1 to fix finalization issues; pool
+> pragmas.]
+> Approve ______ Disapprove ______ Abstain ___X____
+
+I am on the borderline of disapproving this AI because I feel the AI as
+currently worded is significantly broken. There needs to be a way for a
+storage pool implementer to suppress a Default_Storage_Pool pragma used
+as a configuration pragma. I feel that the AI is an important one, though,
+and can probably be fixed with a binding interpretation post Ada 2012, but
+that might involve a new pragma, aspect, or syntax being defined to suppress
+the Default_Storage_Pool pragma, or somehow refer to the storage pool that
+you get if the Default_Storage_Pool pragma is not specified. e.g. pragma
+Suppress_Default_Storage_Pool_Overriding.
+
+Editorial Comment:
+"appplying" in the problem section
+
+Editorial Comment:
+7.6.1(11/3) ", the objects finalized as part of its finalization{, }
+cease to exist, as do any types and subtypes"
+I was having difficulty parsing this sentence. I was reading as "part of the
+finalization of the master ceases to exist", not as "the objects finalized
+during the finalization of the master cease to exist". Perhaps this even a
+better alternative than simply inserting a comma.
+
+Editorial Comment:
+Discussion: "(it is all to easy" => "(it is all too easy"
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Monday, May 16, 2011 4:39 PM
+
+[Appropriate part of a larger message - Editor.]
+
+> AI05-0190-1/11 Global storage pool controls
+> [Uses new term from AI05-0243-1 to fix finalization issues; pool pragmas.]
+> Approve __X___ Disapprove ______ Abstain _______
+>
+
+[Comment: For the access result case the !wording says:
+
+ - For the type of an access result, within the master of the call
+ (see 3.10.2).
+
+The phrase "within the master of the call" doesn't seem precise enough to me.
+Exactly where within the master is the object declared? Presumably it had
+better at least be before the call. Ideally it should be at a point immediately
+preceding the call, but wording for this seems tricky, since the call we're
+talking about depends on the specific master that ends up applying by the rules
+of 3.10.2. This doesn't concern me enough to vote against, but I wanted to
+mention it. End of Comment]
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, May 18, 2011 10:11 PM
+
+...
+> Editorial Comment:
+> 7.6.1(11/3) ", the objects finalized as part of its
+> finalization{, }
+> cease to exist, as do any types and subtypes"
+> I was having difficulty parsing this sentence. I was reading as "part
+> of the finalization of the master ceases to exist", not as "the
+> objects finalized during the finalization of the master cease to
+> exist". Perhaps this even a better alternative than simply inserting a
+> comma.
+
+The sentence in question was added in Ada 2005, and is unchanged in this AI.
+(That's not clear from the AI text, so Bob should avoid complaining about people
+asking to fix existing Ada 2005 text. :-)
+
+The full sentence is:
+
+"After the finalization of a master is complete, the objects finalized as part
+of its finalization cease to *exist*, as do any types and subtypes defined and
+created within the master."
+
+Adding a comma doesn't help anything; if anything it makes it worse by
+separating "cease to exist" from "objects finalized". The "obvious" fix is to
+get rid of "its":
+
+"After the finalization of a master is complete, the objects finalized as part
+of the finalization of the master cease to *exist*, as do any types and subtypes
+defined and created within the master."
+
+That to me is just adding words rather than much clarity; it seems pretty clear
+what "its finalization" refers to.
+
+Your suggestion of replacing "as part of" with "during" might be OK (and it
+probably reads better), but it seems to me that it might be construed to include
+any other objects that happened to be finalized at the same time (by a different
+task, perhaps), and that would be wrong. "As part of" is clearer in that
+respect.
+
+So in the absence of a clear improvement, I'm not going to make any change here.
+But perhaps someone else has a better idea.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, May 18, 2011 10:57 PM
+
+> The phrase "within the master of the call" doesn't seem precise enough
+> to me. Exactly where within the master is the object declared?
+> Presumably it had better at least be before the call. Ideally it
+> should be at a point immediately preceding the call, but wording for
+> this seems tricky, since the call we're talking about depends on the
+> specific master that ends up applying by the rules of 3.10.2. This
+> doesn't concern me enough to vote against, but I wanted to mention it.
+> End of Comment]
+
+This had bothered me in the past, but in the absence of a better idea, I didn't
+do anything about it. As Gary notes, saying more would quickly get confusing,
+because of the difficulty of identifying the master in question.
+
+I've rationalized that the master of a call is usually a very small area, so it
+is hard to come up with a case where it could matter. Beyond that, it doesn't
+really matter if it is before or after the call, since its only effect is
+determine when the collection is finalized, and the call itself does not
+participate in finalization.
+
+I suppose this laxness could be a problem if the "master of the call" is that of
+an access type (as in an initialized allocator); in a long-lived master, the
+place within the master could in fact matter -- especially if it is far away
+from the call's position in the master. Still, it's hard to imagine an
+implementation doing something completely nonsensical here.
+
+Of course, if someone has wonderful wording with the appropriate properties,
+I'll be happy to use it.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, May 18, 2011 11:32 PM
+
+> AI05-0190-1/11 Global storage pool controls
+> [Uses new term from AI05-0243-1 to fix finalization issues; pool pragmas.]
+> Approve ______ Disapprove __X____ Abstain _______
+>
+> ================
+>
+> comment: It is regrettable in this day and age of multicore that we
+> stuck to strict sequentiality in the first sentence of 7.6.1(11),
+> since we were already changing the words. I approve of the
+> finalization wording only because the old wording was much worse and
+> because it is late in the game.
+
+In the abstract, I would agree. But as a practical matter, parallel finalization
+would be a significant compatibility problem. Most existing Finalize routines do
+not protect themselves against parallel execution, and thus many would fail if
+used that way.
+
+Admittedly, the problem can happen by declaring objects of a controlled type in
+different tasks; but it is not unusual for types to be documented as "not task
+safe". For such types, there is no parallelism currently required and adding
+some would be pretty nasty.
+
+I vaguely recall this topic being discussed during the Ada 95 definition, and
+the decision was to not require types to do finalization locked that did not
+need to be "task safe". One could make a fairly strong argument today that that
+decision was wrong, but it seems too late to change it.
+
+(Note that one of the things I wanted to try to get from "superpure"
+categorization, which later turned into global in/out annotations, was the
+permission to evaluate subprograms in parallel if they are declared to have no
+side-effects and their parameters don't conflict. Since the annotations didn't
+survive, neither did the permission.)
+
+> I seriously disagree with the writeup of the Default_Storage_Pool
+> pragma (but not with the general intent of such a pragma.):
+>
+> > The default storage pool for an allocator that occurs within an
+> > instance of a generic is defined by the Default_Storage_Pool pragma
+> > that applied to the generic, or by the Default_Storage_Pool aspect
+> > of the instantiation;
+>
+> add: {and the user shall toss a coin to guess which it is; he may also
+> query the oracle of Delphi or call the language designers at 0-800-...
+> (49c/minute)} i.e., I strongly disagree if this is really the intended
+> un-semantics.
+
+Humm, a "1-900" line for Ada advice. Maybe that can be my next career! ;-)
+
+The static semantics rules say (as part of the definition of the aspect):
+
+This aspect overrides any Default_Storage_Pool pragma that might apply to the
+generic unit.
+
+so the semantics are well-defined. The wording you are reading is in the lengthy
+AARM note that follows the normative definition (it has 5 paragraphs). I presume
+Bob thought that repeating the formal definition in detail was unnecessary.
+
+I switched the words around to make it a bit clearer:
+
+The default storage pool for an allocator that occurs within an instance of a
+generic is defined by the Default_Storage_Pool aspect of the instantiation (if
+specified), or by the Default_Storage_Pool pragma that applied to the generic;
+the Default_Storage_Pool pragma that applies to the instantiation is irrelevant.
+
+> > the Default_Storage_Pool pragma that applies to the instantiation is
+> > irrelevant.
+>
+> surprising: what happened to the notion that aspect pragmas do specify
+> aspects?
+
+The Default_Storage_Pool pragma is a configuration pragma, not an aspect pragma.
+(It applies to the entire partition, not to any single entity.) The aspect is
+something different (it just applies to generic instantiations).
+
+This is the same reason that Discard_Names is not an aspect pragma, even though
+it is possible to imagine a Discard_Names aspect, and the pragma has the right
+form for an aspect pragma.
+
+****************************************************************
+
Questions? Ask the ACAA Technical Agent