CVS difference for ai05s/ai05-0190-1.txt

Differences between 1.20 and version 1.21
Log of other versions for file ai05s/ai05-0190-1.txt

--- ai05s/ai05-0190-1.txt	2011/11/01 05:32:53	1.20
+++ ai05s/ai05-0190-1.txt	2012/01/26 07:43:09	1.21
@@ -146,7 +146,7 @@
 Default_Storage_Pool aspect is Root_Storage_Pool'Class. The aspect_definition
 must be a name that denotes a variable. This aspect overrides any
 Default_Storage_Pool pragma that might apply to the generic unit; if the aspect
-is not specified, the default pool of the instance is that defined for the generic unit. 
+is not specified, the default pool of the instance is that defined for the generic unit.
 
 For nonderived access types declared in places where the default pool is defined
 by the pragma or aspect, their Storage_Pool or Storage_Size attribute is determined
@@ -3607,6 +3607,191 @@
 of the AI - Editor.]
 
 Thanks you, Steve, for your help!
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Friday, April 1, 2011  12:57 PM
+
+During the last ARG phone meeting we started to discuss the wording for
+collection finalization in the latest version of AI05-190, but ended up
+deferring that pending discussion of AI05-234, which also got deferred.  The
+concern was the definition for access results based on the wording "determined
+by the point of call".
+
+I took a look at the issue of wording for the access result case and have the
+following comment, given below (plus minor comments on the wording for the
+access parameter case).
+
+> New version of AI05-0190-1, Global storage pool controls.
+>
+> ...
+>
+> Each nonderived access type T has an associated "collection", which is
+> the set of objects created by allocators of T, or of types derived from T.
+> Unchecked_Deallocation removes an object from its collection.
+> Finalization of a collection consists of finalization of each object
+> in the collection, in an arbitrary order. The collection of an access
+> type is an object implicitly declared at the following place:
+>
+>     - For a named access type, the first freezing point (see 13.14) of
+>       the type.
+>
+>     - For the type of an access parameter, the call that contains the
+>       allocator.
+
+This may be picky, but instead of saying "contains the allocator", I'd prefer
+something like "contains an allocator of the type", because the wording "the
+allocator" seems like it refers to some allocator mentioned earlier (that is, it
+has an unclear referent).
+
+Also, I wonder if it's clear enough that the collection must be declared within
+the master associated with the call, rather than within the enclosing master.
+Maybe it's fine as is, I just mention it in case anyone else thinks it may need
+more precision.
+
+>     - For the type of an access result, at the place where the accessibility
+>       level is determined by the point of call (see 3.10.2).
+> [Note: This is a reference to AI05-0234-1.]
+
+As noted in the phone meeting, the above wording doesn't say the right thing.
+
+There are places (such as a return statement) where accessibility is said to be
+determined by the point of call, but that's not where we want the collection to
+be declared.  Usually we want it to be declared where the call occurs.  More
+specifically, we want it declared at the point of call and within the enclosing
+master of the call, not the within the master associated with the call itself.
+And in the case where the call itself defines the result of an enclosing
+function with an access result, we want to push it out to the level of the call
+to that function (or to its caller, recursively).  In any case, I don't think we
+want to refer to accessibility levels here, though we may want to refer to the
+point or place of a call.
+
+As for capturing this in wording, that seems a little tricky.
+
+Here's a stab (ignoring the nested call business for the moment):
+
+    - For the type of the access result of a function call, at the place
+      of the call, within the innermost master of the call;
+
+That's awkward, and also doesn't seem quite right, because it doesn't capture
+the need for the declaration point to be within the enclosing master, but not
+associated with the master that the function call itself represents.  Do we have
+an established way to make that distinction?  (It seems like we must, but I
+couldn't find it.) I hate to make this more verbose by adding something to the
+effect "... but not within the master defined by the call..." or some such
+blather.  Can we say "immediately within the innermost master..." or something
+to that effect?
+
+Now we need to add handling for nested calls returning access results.
+
+As a straw man, how about:
+
+   "... unless the call defines the result of a function with an access result,
+    in which case the collection is declared at the place of the call to that
+    function, and so on recursively."
+
+Not great.  There's probably a better way of saying this.  Anyone else want to
+take a shot at the wording?
+
+There's also the formality of accounting for cases where the function call of a
+return statement is wrapped in parentheses and qualified expressions (and
+conversions?).  I suggest ignoring that until we get the basic semantics
+expressed properly.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, April 1, 2011  3:26 PM
+
+Thanks for looking at this, Gary.  I'm frustrated, because this AI is really
+about a simple memory-allocation gizmo, and somehow (because of a bug in some
+OTHER AI) I got stuck with arcane accessibility-related issues, which are only
+vaguely related to this AI.  I appreciate any help with those!
+
+> >     - For the type of an access parameter, the call that contains the
+> >       allocator.
+>
+> This may be picky, but instead of saying "contains the allocator", I'd
+> prefer something like "contains an allocator of the type", because the
+> wording "the allocator" seems like it refers to some allocator
+> mentioned earlier (that is, it has an unclear referent).
+
+OK.
+
+> Also, I wonder if it's clear enough that the collection must be
+> declared within the master associated with the call, rather than
+> within the enclosing master.  Maybe it's fine as is, I just mention it
+> in case anyone else thinks it may need more precision.
+
+Maybe an AARM note?
+
+> >     - For the type of an access result, at the place where the accessibility
+> >       level is determined by the point of call (see 3.10.2).
+> > [Note: This is a reference to AI05-0234-1.]
+>
+> As noted in the phone meeting, the above wording doesn't say the right thing.
+>
+> There are places (such as a return statement) where accessibility is
+> said to be determined by the point of call, but that's not where we
+> want the collection to be declared.  Usually we want it to be declared
+> where the call occurs.  More specifically, we want it declared at the
+> point of call and within the enclosing master of the call, not the
+> within the master associated with the call itself.  And in the case
+> where the call itself defines the result of an enclosing function with
+> an access result, we want to push it out to the level of the call to
+> that function (or to its caller, recursively).  In any case, I don't
+> think we want to refer to accessibility levels here, though we may want to
+> refer to the point or place of a call.
+
+All true.  But the "determined by point of call" stuff in AI05-0234-1 captures
+all that.  I realize I'm committing a category error; AI05-0234-1 talks about
+accessibility levels, whereas here we're talking about places.  But those places
+are intimately tied to the those levels (or maybe 'tother way 'round).
+
+> As for capturing this in wording, that seems a little tricky.
+
+Indeed!
+
+> Here's a stab (ignoring the nested call business for the moment):
+>
+>     - For the type of the access result of a function call, at the place
+>       of the call, within the innermost master of the call;
+>
+> That's awkward, and also doesn't seem quite right, because it doesn't
+> capture the need for the declaration point to be within the enclosing
+> master, but not associated with the master that the function call
+> itself represents.  Do we have an established way to make that
+> distinction?  (It seems like we must, but I couldn't find it.) I hate
+> to make this more verbose by adding something to the effect "... but
+> not within the master defined by the call..." or some such blather.  Can we
+> say "immediately within the innermost master..."
+> or something to that effect?
+>
+> Now we need to add handling for nested calls returning access results.
+>
+> As a straw man, how about:
+>
+>    "... unless the call defines the result of a function with an access result,
+>     in which case the collection is declared at the place of the call to that
+>     function, and so on recursively."
+>
+> Not great.  There's probably a better way of saying this.  Anyone else
+> want to take a shot at the wording?
+
+All of the above is on the right track.  Perhaps we should change AI05-0234-1 to
+talk about places, or calls ("the ultimately relevant call"), or something, and
+then tie accessibility levels to that.  And then this AI has something other
+than accessibility levels to refer to, thus avoiding the category error.
+
+More discussion needed.
+
+> There's also the formality of accounting for cases where the function
+> call of a return statement is wrapped in parentheses and qualified
+> expressions (and conversions?).  I suggest ignoring that until we get
+> the basic semantics expressed properly.
+
+Agreed.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent