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

--- ai05s/ai05-0148-1.txt	2009/04/30 06:09:30	1.3
+++ ai05s/ai05-0148-1.txt	2009/06/08 03:52:05	1.4
@@ -1,4 +1,4 @@
-!standard 3.10.2(13/2)                                 09-04-29  AI05-0148-1/03
+!standard 3.10.2(13/2)                                 09-06-06  AI05-0148-1/04
 !standard 3.10.2(19/2)
 !standard 4.6(24.17/2)
 !standard 4.6(48)
@@ -170,6 +170,86 @@
 being of local accessibility.  There seems little need for the
 dynamic flexibility we are proposing here for access-to-object types,
 because access-to-subprogram parameters are not dynamic.
+
+Implementation Issues
+
+Because access-to-object parameters already have dynamic accessibility
+levels, the intent is that these stand-alone variables may be handled
+in a very similar way.  Furthermore, if there are no access-to-object
+parameters in scope, then all of the accessibility levels of interest
+will be static, and hence essentially all of the checking can be performed
+at compile-time given some level of flow analysis.
+
+One important difference between the stand-alone access variables and
+access parameters is that one can assign a local access parameter to
+a more global stand-alone access variable.  This is similar to the
+problem of calling a subprogram at a higher level and passing along
+an access parameter.  Similarly, one can assign a more global access
+parameter to a more local stand-alone access variable.
+AARM 3.10.2(22.dd/2) addresses the issue of passing an access parameter
+along to another subprogram:
+
+   * If the actual is an access parameter of an access-to-object type, 
+     usually just pass along the level passed in. However, if the static 
+     nesting level of the formal (access) parameter is greater than the 
+     static nesting level of the actual (access) parameter, the level 
+     to be passed is the minimum of the static nesting level of the 
+     access parameter and the actual level passed in. 
+     
+Note also the paragraph 22.ee indicates that the accessibility level
+passed in for an access parameter is to be ignored when converting
+to a local access type.  This is because the accessibility level passed
+in might be deeper than that of the called subprogram.  So the "true"
+static accessibility level for an access parameter is generally the
+minimum of the passed in value and the static accessibility level of
+the subprogram itself.  This must be remembered when assigning
+the accessibility level of an access parameter to that of a stand-alone
+object.  This "min" operation should probably be performed explicitly
+at that point.
+
+So what can we say about an assignment from an access parameter
+(or access variable) at one level to a stand-alone access variable 
+at some other level?  First, we should assume the accessibility level
+is normalized as suggested above, namely the value passed in with
+an access parameter is compared against the static level of the
+called subprogram, and reduced to that level if the passed-in value
+is greater.  Then the normalized value can safely be assigned to an access
+variable at some other level, subject to first checking that
+it is not deeper than that of the access variable being assigned.
+The normalized value corresponds to the static nesting level, and
+hence is meaningfully compared and assigned to all visible nesting
+levels.
+
+For example:
+
+     procedure P(X : access T) is
+        Y : access T;
+        procedure Q is
+            Z : access T := X;  -- normalize level here
+        begin
+            Y := Z;  -- this is always safe but might
+                     -- fail if level of X not normalized
+                     -- before being assigned to Z.
+        end Q;
+     begin
+         Q;
+     end P;
+            
+
+Interaction with Tasking
+
+Tasking imposes certain additional concerns with respect to accessibility.
+In particular, inside an accept body, there are two independent stacks
+that are effectively coming together, potentially producing accessibility
+levels that cannot be meaningfully compared.  However, access parameters are
+not permitted on entry calls, and there are no OUT parameters of
+an anonymous access type, so in fact accessibility levels from the
+task entry caller never enter into the picture, and we can follow
+the "normal" rules.  Up-level references across a task body boundary
+also do not create any special problems (other than the usual danger
+of unsynchronized access to shared variables), because the task body
+is just like a subprogram body from the point of view of static nesting
+and accessibility levels.
 
 
 !example