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

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

--- ai05s/ai05-0138-1.txt	2009/03/21 02:26:03	1.3
+++ ai05s/ai05-0138-1.txt	2009/04/30 06:19:47	1.4
@@ -25,7 +25,7 @@
 
 (1) Some sort of accessibility test that a programmer can write. (An
 "accessibility membership" was suggested.) Presumably, this could be used to
-enhance the contract of a subprogram.
+enhance the contract of a subprogram. [This is now AI05-0149-1.]
 
 (2) Some modifications to the accessibility of stand-alone anonymous access
 objects. Tucker had suggested some sort of dynamic accessibility for them.
@@ -33,6 +33,7 @@
 and determined that it is not implementable without serious distributed
 overhead. So this would have to be limited in the accessibility that could
 possibly be saved in it - it would be some sort of hybrid approach.)
+[This is now AI05-0148-1.]
 
 (3) Some mechanism (a restriction pragma??) to ensure that no allocators of
 anonymous access types are used in a unit. (Anonymous access types can't have a
@@ -3082,211 +3083,6 @@
 
 ****************************************************************
 ========= End of thread ==========
-==== New thread: A proposal for idea (1)  =========
-(Testing the accessibility level)
-****************************************************************
-
-From: Franco Gasperoni
-Date: Friday, November 14, 2008  1:54 PM
-
-Right now a developer has no simple way to defend its code against accessibility
-level problems, in particular should the user disable all checks.
-
-To that extent we could define a new attribute 'Level, where for any entity E
-for which an accessibility level is defined:
-
-    E'Level returns a Natural which represents the accessibility
-            level of E (better a private type with
-            <, >, <=, >=, =, and a constant for the library_level
-            and something to print it as an integer for teaching purposes)
-
-As an example and using Natural for 'Level consider the following:
-
-    package Pack is
-       G : access Integer := new Integer'(0);
-       --  G'Level = 0
-       --  G.all'Level = 0
-
-       procedure P (X : not null access Integer);
-    end Pack;
-
-    package body Pack is
-       procedure P (X : not null access Integer) is
-          --  X.all'Level = accessibility level of the object
-                            pointed to by the actual
-
-          Y : access Integer := G;
-          --  Y'Level = 1
-          --  Y.all'Level = 0
-       begin
-          null;
-       end P;
-    end Pack;
-
-    with Pack; use Pack;
-    procedure Main is
-       W : aliased Integer;
-       --  W'Level = 1
-    begin
-       P (G);
-       --  Inside P, X.all'Level = 0
-
-       P (W'Access);
-       --  Inside P, X.all'Level = 1
-    end Main;
-
-Why is 'Level useful? Let's assume we have some preexisting code like
-
-    type Cell is tagged record
-       Next : access Cell'Class;
-    end record;
-
-    procedure Insert (X, Y : not null access Cell'Class) is;
-    begin
-       Y.Next := X.Next;
-       Y.Next := Y;  --  Accessibility check we cannot defend against
-    end;
-
-If we use 'Level we can defend against the accessibility problem as follows
-
-    procedure Insert (X, Y : not null access Cell'Class) is;
-    begin
-       if Y.all'Level <= X.Next'Level then
-          Y.Next := X.Next;
-          Y.Next := Y;
-       else
-          ...
-       end if;
-    end;
-
-Note that if instead of "not null" the Y access parameter can be null then we
-have to write
-
-    procedure Insert (X : not null access Cell'Class;
-                      Y :          access Cell'Class) is;
-    begin
-       if Y /= null and then Y.all'Level <= X.Next'Level then
-          Y.Next := X.Next;
-          Y.Next := Y;
-       else
-          ...
-       end if;
-    end;
-
-****************************************************************
-
-From: Randy Brukardt
-Date: Friday, November 14, 2008  3:28 PM
-
-> Right now a developer has no simple way to defend its code against
-> accessibility level problems, in particular should the user disable
-> all checks.
-
-I would be in favor of allowing more control of accessibility.
-
-But I don't see any reason to worry about cases where the user has disabled all
-checks (that is, pragma Suppress). By doing so, they are telling the compiler:
-"I've thoroughly tested this program, and I'm certain that no checks are needed.
-Make the program as fast as possible, but I understand that if I'm wrong that no
-checks are needed, the program will fall over dead."
-
-> To that extent we could define a new attribute 'Level, where
-> for any entity E for which an accessibility level is defined:
->
->     E'Level returns a Natural which represents the accessibility
->             level of E (better a private type with
->             <, >, <=, >=, =, and a constant for the library_level
->             and something to print it as an integer for teaching purposes)
-
-You seem to be confusing static and dynamic accessibility. This attribute would
-presumably be testing the static accessibility (since you seem to expect that it
-can be represented as an integer), which is not what the dynamic checks test.
-Moreover, there is no way to easily describe dynamic accessibility, since
-"incomparable" is a possible result. (It comes up with tasks and class-wide
-types; if we generalized accessibility at all, it most likely would come up with
-all access types as well.)
-
-Steve points out that there ought to be a membership for accessibility, which
-seems like a better idea (an operation to compare to accessibility of two
-values, not a way to make that into an object). That probably would mitigate
-your concern.
-
-My thought on accessibility is that Tucker wants to extend dynamic accessibility
-checks into more places (anonymous access returns; stand-alone objects). But
-this is something that could be useful in all contexts. And it has a runtime
-overhead, so declaring that you don't want it also would seem useful in all
-contexts. (Specifically, it would be nice to be able to declare static
-accessibility for an access parameter, if it is intended only to take existing
-library level objects or some such. Dynamic accessibility always implies the
-possibility of passing in something that causes something to break further down
-the line, and that makes routines more fragile than they have to be.)
-
-This comes back to Bob's idea that we don't really want features where you have
-to do things a certain way (in this case, use anonymous access types) in order
-to get some other useful but unrelated feature (dynamic accessibility checks).
-
-So I wonder if it would make sense to allow an access type (*any* access type,
-named or anonymous) to declare that it wants to use dynamic accessibility (or
-static accessibility!) -- then the programmer can decide between the static
-checks that never seem to actually work and dynamic checks that work but are
-expensive.
-
-One could go even further and allow an access type to have a static
-accessibility that is deeper than where it is declared. (That would seem to have
-value only for anonymous access types, so I don't think it is worth it.)
-
-I haven't thought about the details of this idea too much, since I wanted to
-find out if I was the only one thinking this way. So perhaps there is a giant
-hole in it somewhere.
-
-****************************************************************
-
-From: Franco Gasperoni
-Date: Saturday, November 15, 2008  5:01 AM
-
-> Steve points out that there ought to be a membership for
-> accessibility, which seems like a better idea (an operation to compare
-> to accessibility of two values, not a way to make that into an
-> object). That probably would mitigate your concern.
-
-Absolutely, that would solve it
-
-> My thought on accessibility is that Tucker wants to extend dynamic
-> accessibility checks into more places (anonymous access returns;
-> stand-alone objects). But this is something that could be useful in all contexts.
-
-Tuck is right on track there and I agree with your statement.
-
-> And it
-> has a runtime overhead, so declaring that you don't want it also would
-> seem useful in all contexts. (Specifically, it would be nice to be
-> able to declare static accessibility for an access parameter, if it is
-> intended only to take existing library level objects or some such.
-> Dynamic accessibility always implies the possibility of passing in
-> something that causes something to break further down the line, and
-> that makes routines more fragile than they have to be.)
-
-Yes
-
-> This comes back to Bob's idea that we don't really want features where
-> you have to do things a certain way (in this case, use anonymous
-> access types) in order to get some other useful but unrelated feature
-> (dynamic accessibility checks).
->
-> So I wonder if it would make sense to allow an access type (*any*
-> access type, named or anonymous) to declare that it wants to use
-> dynamic accessibility (or static accessibility!) -- then the
-> programmer can decide between the static checks that never seem to
-> actually work and dynamic checks that work but are expensive.
-
-That is a very interesting thought indeed. In particular if we could "request"
-and be guaranteed that all anonymous access to a given designated type T have
-(say) static library-level accessibility then local anonymous allocators would
-have to be allocated on the heap and would allow us to present anonymous access
-as the natural match to the * T of C/C++ (except that it is safer :)
-
-****************************************************************
-========= End of thread ==========
 ====== New thread: A discussion of idea (4)  =========
 (Call-level accessibility)
 ****************************************************************
@@ -4671,6 +4467,54 @@
 Java and C# over Ada.  I'd rather spend my time implementing GC than
 implementing arcane dynamic accessibility checks.  (OK, I admit I'm exaggerating
 -- an efficient GC is a LOT of work.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, March 18, 2009  9:38 PM
+
+Randy made the interesting suggestion that we make the accessibility
+level you get when you take 'Access of a part of a parameter be that
+of the call, rather than that of a local variable of the subprogram.
+It took me a while to understand the point, but I think I get it now
+and I don't see any major problem with this, and it does seem to
+provide additional flexibility.
+
+This distinction didn't really make much difference in Ada 95, nor
+even in Ada 2005, but in the context of AI05-51, where we propose that
+the accessibility check performed against a function result of an
+anonymous access type is determined by the context of the call, this
+distinction would allow something like:
+
+
+     type T is record
+        ...
+        C : aliased Comp_Type;
+     end record;
+
+
+     function Cee(X : T)
+       return access constant Comp_Type is
+     begin
+        return X.C'Access;  -- currently illegal
+     end Cee;
+
+
+     procedure P(Y : access constant Comp_Type);
+
+     ...
+
+     P(Cee(X));
+
+That is, the accessibility check on the function result would succeed,
+so long as the context of the call is not expecting the result to outlive
+the innermost master of the call.
+
+This gets more interesting if functions can have in-out parameters, by
+the way, since then the function result type in this example could be
+"access Comp_Type" rather than "access constant Comp_Type."  Probably
+that would argue for only allowing this "extra" level for parameters that
+are required to be passed by reference, e.g. are of a tagged record type.
 
 ****************************************************************
 ========= End of thread ==========

Questions? Ask the ACAA Technical Agent