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

Differences between 1.2 and version 1.3
Log of other versions for file ai05s/ai05-0148-1.txt

--- ai05s/ai05-0148-1.txt	2009/04/13 23:53:39	1.2
+++ ai05s/ai05-0148-1.txt	2009/04/30 06:09:30	1.3
@@ -1,6 +1,7 @@
-!standard 6.01 (18)                                 09-04-13  AI05-0148-1/02
-!standard 6.06 (03)
-!standard 9.5.1 (02)
+!standard 3.10.2(13/2)                                 09-04-29  AI05-0148-1/03
+!standard 3.10.2(19/2)
+!standard 4.6(24.17/2)
+!standard 4.6(48)
 !class Amendment 09-04-12
 !status work item 09-04-12
 !status received 09-04-12
@@ -173,6 +174,34 @@
 
 !example
 
+    type Root_Node is tagged record
+        Next : access Root_Node'Class;
+    end record
+
+
+    function Reverse(List : access Root_Node'Class)
+      return access Root_Node'Class is
+      -- Reverse the order of the nodes of the list
+        Result : access Root_Node'Class := null;
+        This_Node : access Root_Node'Class := List;
+    begin
+        -- Iterate through the nodes moving them to the beginning of
+        -- the new list.
+        while This_Node /= null loop
+            -- Put this node on front of new list
+          declare
+            Next_Node : constant access Root_Node'Class := This_Node.Next;
+          begin
+            Next_Node := This_Node.Next;
+            This_Node.Next := Result;  -- Fails accessibility check
+            Result := This_Node;
+
+            -- advance to next node on list
+            This_Node := Next_Node;
+          end;
+        end loop;
+        return Result;  -- Fails accessibility check
+    end Reverse;
 
 
 !ACATS test
@@ -183,6 +212,146 @@
 
 [This idea grew out of the volumnous e-mail threads found in
 AI05-138-1. - Editor.]
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, March 18, 2009  9:08 PM
+
+Randy asked me to write up something more formal on my proposal for
+standalone objects of an anonymous access type.  Franco gave a quite
+good argument in my view that the current Ada 2005 accessibility rules
+for these objects makes them essentially useless.
+
+So here is a proposal to make their accessibility level come from their
+assigned value, modulo the requirement that they can never designate an
+object shorter-lived than themselves.
+
+---
+
+!problem
+
+The accessibility level of a stand-alone object of
+an anonymous access type is defined, in Ada 2005, to
+be the same as the master in which it is declared.
+Unfortunately, this is relatively useless.  It can
+safely point at anything, but it immediately loses track
+of the accessibility level of its target, so the value
+can't be copied back into any pointer that is longer-lived.
+That means you can't use one of these for the most basic purpose
+of swapping two values that have longer lives.
+
+An example of this comes up when trying to reverse
+the nodes of a linked list, presuming the "Next" component 
+of each node is of an anonymous access type:
+
+   type Node is record
+       ...
+       Next : access Node;
+   end record
+   
+   
+   function Reverse(List : access Node) return access Node is
+     -- Reverse the order of the nodes of the list
+       Result : access Node := null;
+       This_Node : access Node := List;
+   begin
+       -- Iterate through the nodes moving them to the beginning of
+       -- the new list.
+       while This_Node /= null loop
+           -- Put this node on front of new list
+         declare
+           Next_Node : constant access Node := This_Node.Next;
+         begin
+           Next_Node := This_Node.Next;
+           This_Node.Next := Result;  -- Fails accessibility check
+           Result := This_Node;
+           
+           -- advance to next node on list
+           This_Node := Next_Node;
+         end;
+       end loop;
+       return Result;  -- Fails accessibility check
+   end Reverse;
+
+As indicated in comments, assigning into a local variable is
+no problem, but assigning *from* it is very likely to fail an
+accessibility check in any useful algorithm.
+
+!proposal
+
+We propose to allow the accessibility level of a stand-alone 
+object of an anonymous access type to vary during its lifetime,
+taking on the level of the value from which it is assigned,
+provided that level is no deeper than the level of the master
+in which the stand-alone object is declared.  This restriction
+is enforced with the usual pair of a legality rule and
+a dynamic semantics rule, as follows:
+
+In an assignment to a stand-alone object of an anonymous
+access type, the accessibility level of the RHS shall not be 
+statically deeper than that of the master in which the object is declared.  
+
+A (run-time) check is performed on such an assignment that the (dynamic) 
+accessibility level of the RHS is no deeper than that of the master 
+in which the object is declared.  If the check fails, Program_Error 
+is raised.
+
+Note that a library-level object of an anonymous access type
+can only designate library-level objects.
+
+The null value is considered libary-level for the purposes
+of these checks.
+
+!discussion
+
+The current rule in Ada 2005 makes standalone objects of an
+anonymous access type useful only to point at local objects,
+which is not of any significant value.  We considered various
+ways of fixing this.  One was to have them take on the
+accessibility level of their initial value, analogous to
+the way the access parameters and access object renames work.
+This certainly seems more useful, but it is not clear what
+to do when an object is initialized to null.  Normally one
+would think of null as being library-level, but perhaps it
+is better thought of being no particular level.
+
+An alternative idea was to require that all non-null values
+assigned to a given access object be of the same accessibility
+level.  This works fine for static accessibility levels, but is
+not very practical for dynamic accessibility levels, such as
+those of access parameters, as it would essentially require a
+separate value against which each newly assigned value would
+be compared, and which would be initialized from each non-null
+assignment.
+
+The simplest idea seems to have stand-alone objects take on
+the accessibility level of their assigned value.  This makes
+complete sense for constants, it is already what happens for
+object renames and access parameters, and it is only for
+variables that we have a somewhat new notion.  It clearly is
+more flexible than the current rule or the single-non-null-level
+rule, and is probably less likely to cause surprises or
+problems.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 18, 2009  10:51 PM
+
+Thanks for doing this.
+
+I see the rules for assigning *to* an anonymous access object.
+
+But I don't see any definition here of what the accessibility level
+an anonymous access object is (that is, assigning *from* such an object).
+I presume you will need to change some rules in 3.10.2 to make this
+partially dynamic accessibility happen. You surely don't want 3.10.2(7)
+to apply; I suppose you want something like 3.10.2(11.1/2) or 3.10.2(13/2)
+to apply. But I don't want to guess quite what is meant here - I've been
+wrong before.
+
+(BTW: Might fix "libary level" for null, while you are at it.)
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent