CVS difference for ais/ai-10318.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-10318.txt

--- ais/ai-10318.txt	2004/04/06 21:51:16	1.1
+++ ais/ai-10318.txt	2004/04/30 02:35:39	1.2
@@ -763,3 +763,170 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Thursday, April 15, 2004,  10:30 AM
+
+In my recent AI-318-2 proposal for functions returning
+an anonymous access type, I had specified that
+implicit dereference was provided for calls on
+such functions, in part to minimize the impact
+of eliminating return-by-reference functions.
+
+However, since then I noticed an additional use
+of implicit deref of such calls.  I mentioned this
+in a response to ada-comment, but here I repeat
+it for those who don't follow that mailing list.
+
+There are often times where one wants to provide
+a read-only view of a "private" global variable.
+There are also times that you have a large global
+table, but you want to put its initialization in
+a package body so you don't suffer recompilation
+headaches every time you change the table slightly
+(e.g. a large parse table).
+
+Ada doesn't really have any good solution for this.
+
+In C/C++, you can declare a large constant (or
+variable) without giving its initialization in a
+spec (i.e. the ".h" file), and then in the body
+(i.e. the ".c" file) give the full initialization.
+
+With this new implicit deref proposal, it would
+make it pretty easy and efficient to solve this
+problem:
+
+    In the spec:
+
+        function Read_Only_View return access constant T;
+        pragma Inline(Read_Only_View);
+
+    In the body:
+
+        Var : aliased T := (...);
+
+        function Read_Only_View return access constant T is
+        begin
+            return Var'Access;
+        end Read_Only_View;
+
+Similarly, if there were a large constant table that you just
+wanted to postpone to the body:
+
+    In the spec:
+         function Parse_Table return access constant Parse_Table_Type;
+         pragma Inline(Parse_Table);
+
+    In the body:
+         Parse_Table_Obj : aliased constant Parse_Table_Type := (...);
+
+         function Parse_Table return access constant Parse_Table_Type is
+         begin
+             return Parse_Table_Obj'Access;
+         end Parse_Table;
+
+Since the existing uses of anonymous access types are
+quite limited right now (only parameters and discriminants),
+we could consider providing implicit dereference for *all*
+expressions of an anonymous access type, since that would
+be more uniform.  But I also think it is not too bad to
+only provide this for calls, since there is already
+implicit "deproceduring" (as Algol 68 called it) for parameterless
+subprograms in Ada.   Providing implicit deref for functions
+returning an anonymous access type seems like a natural
+progression of that.
+
+If we instead choose to extend implicit deref to all anonymous
+access values, then there is more of an upward compatibility
+concern, since there could be additional ambiguities created
+when an access parameter or discriminant is passed to an
+overloaded subprogram with one version having a param
+of type "T" and another a param of type "access T".
+Given the relatively modest use of access parameters
+and access discriminants at this point, this seems relatively
+unlikely, and in any case it will not silently change meaning --
+you'll get a compile-time error.
+
+I could go either way.  I think implicit deref of function
+calls at least is pretty important.  It is a very nice way
+to return a reference to a large object without incurring
+significant overhead, and without having to change the syntax
+used at the call point (i.e., no need to insert ".all").
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, April 15, 2004,  10:37 AM
+
+> Ada doesn't really have any good solution for this.
+
+I am missing something, it seems quite reasonable to return
+an appropriate constant access type. Yes you add some nice
+syntactic sugar below, but nothing fundamental.
+
+What am I missing?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, April 15, 2004,  11:32 AM
+
+We have generalized the availability of
+anonymous access types, in part to go with
+the "limited with" proposal, since "limited with"
+doesn't solve the proliferation of access types
+problem.  The one significant place where
+anonymous access types weren't permitted was
+as function result types.  AI-318-2 was addressing that
+(as well as limited result types).  Franco was
+extremely keen on getting this, because he felt
+that it was a clear hole when trying to explain
+the new anonymous access type paradigm.
+
+The implicit deref of calls of such functions may
+seem like a small point, but it can have a significant
+effect on usability in my experience.  Having to add
+".all" on the result of a function call is a pain
+and changes the perceived nature of the abstraction.
+What you really want is return by reference in some
+contexts, and having to add an explicit ".all" makes
+the abstraction feel less abstract.  I gave examples
+of an "array" abstraction with the ability to
+assign to components of the array.
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Thursday, April 15, 2004,  4:22 PM
+
+I don't think you are missing anything.  But that doesn't mean that what
+Tucker is trying to accomplish is not very useful.  Right now you can
+convert a function to an array in some cases and not have to change the
+code that uses the abstraction.  This does the same thing for anonymous
+access types.  (Actually, Tucker goes further, but I think that the
+anonymous access cases are the high payoff.)  If we can eliminate
+gratuitous uses of .all and 'Access, it makes programming in Ada
+easier.  There is a potential problem in that overloadings will be
+possible where supplying the .all (or 'Access) will resolve the
+overloading but the direct call will always be ambiguous.
+
+If you really find that a problem, is should be easy enough to say that
+if a function call or argument is in parentheses, the .all or 'Access
+must be explicit.  So if:
+
+X := Foo(Y, Bar);  -- is ambiguous
+
+then;
+
+X := Foo(Y, (Bar));
+
+and
+
+X := Foo(Y, Bar.all);
+
+Would resolve to the two different meanings.  It might require some
+changes to existing code, but not that much, and it would of course, be
+caught at compile time.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent