CVS difference for ais/ai-00318.txt

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

--- ais/ai-00318.txt	2002/10/10 17:41:47	1.1
+++ ais/ai-00318.txt	2003/01/24 04:14:27	1.2
@@ -882,3 +882,157 @@
+From: Tucker Taft
+Sent: Sunday, January 12, 2003,  7:55 PM
+When we presented some of the Ada 200Y ideas
+at SIGAda, there was a feeling that if we
+added support for aggregates of a limited
+type, we should also have function returns.
+Bob and I don't feel the two need to be tied
+that closely together, but they both go in the
+category of making limited types less limited.
+In any case, I got to thinking about the problem
+more, and wrote the following note to Bob
+describing a "brainstorm" I had a couple of nights
+ago.  Bob said I might as well forward this to
+the full ARG for comments.  He hasn't decided whether
+he will incorporate it into an AI on limited function
+So, fire away.
+I realized sometime after I gave my quick
+response on constructor functions, that I had
+forgotten about one of the main challenges, namely
+the desire to execute some statements (assignments,
+procedure calls, etc.) to initialize the object
+being returned, before actually returning it.
+If the only thing you can do is return an
+aggregate or another function call, you don't
+have much flexibility, and there is no way to
+insert a call on a procedure.
+Which got me to thinking about the various special
+naming conventions we had talked about for local
+variables which *must* be returned, all of which
+were unsatisfactory, kludgey, inelegant, etc.
+And then suddenly the idea came to me that if you
+could attach the statements directly to the
+return statement, that would be nice.
+E.g. something like:
+     return blah with {statement} end return;
+But then you need a name for the object being returned,
+so that led to something like:
+     return X : blah with {statement} end return;
+And then I thought, what construct in Ada already has
+an optional set of statements following it?  The
+"accept" statement.  So why not try to make use of the
+lonely "do" reserved word.  Also, it seems odd to have
+a name on an expression, so let's make it a regular declaration
+with a subtype indication as well.  The leads to:
+    return_statement ::=
+       RETURN ;
+     | RETURN expr ;
+     | RETURN identifier : subtype_indication [:= expr]
+         [ DO
+              handled_sequence_of_statements
+           END [identifier] ;
+         ]
+For example:
+     function Cool(B : Boolean) return Variant_Rec is
+     begin
+        if B then
+            return Result : Variant_Rec(True) do
+                Fixup(Result);
+            end Result;
+        else
+            return Result : Variant_Rec(False) do
+                Different_Fixup(Result);
+            end Result;
+        end if;
+     end Cool;
+With this construct, we could allow limited function
+returns, where either the second form of "return" statement
+is used and the expr is an aggregate or a function call
+(or a reference to a long-lived existing object, per Ada 95),
+or the third form of the "return" statement is used, and
+pretty much anything goes, since you are clearly creating
+a new object.
+This construct would also make it possible to support
+a result type that was an anonymous access type.  E.g.:
+     function Cooler(Blah : access T) return access U is
+     begin
+         return Result : access U := new U(discrim => blah) do
+             Result.Fum := Blah;
+         end Result;
+     end Cooler;
+and the caller could determine the storage pool used for
+"Result" from context:
+     X : U_Ptr := Cooler(Something'Access);
+In fact, limited function returns and anonymous access-type returns
+could be seen as almost the same thing.  To implement both,
+the caller has to pass in a storage pool, and an accessibility
+level.  The called routine can either use that storage pool
+(and its associated finalization/dependent-task list, if needed),
+or it can return an access/reference to an existing object, so
+long as it satisfies the accessibility check.  There might
+be an accessibility level indication or some other flag that
+means the return object *must* be newly allocated out of the
+given storage pool.  The compiler would also have to implicitly
+create a local storage pool to be passed in when the result
+of the function call is used to initialize a local variable.
+I suppose one could get even more radical, and allow this
+"do ... end identifer;" at the end of any declaration that
+is declaring only one object (i.e. isn't "X, Y : Blah").
+This would solve the old problem of making sure any initialization
+procedures that need to be called get connected tightly to
+the declaration.  But that problem could probably be solved
+better by having limited functions with the "return ... do ... end ID;"
+construct, so I think I will keep this more radical suggestion
+to myself ;-).
+So, that was my great "brainstorm" last night (well, actually
+this morning when I couldn't sleep...).  As they used to
+say during the 9X project, I'll go don my flak jacket now,
+so feel free to fire away.
+From: Dan Eilers
+Sent: Monday, January 13, 2003  1:01 PM
+Tuck's proposal looks interesting to me.
+I particularly like the idea of somehow solving "the old problem
+of making sure any initialization procedures that need to be called
+get connected tightly to the declaration."
+Being able to attach initialization code to declarations is useful
+for a variety of reasons, including eliminating the overhead of
+default initialization code where explicit initialization is
+provided later, and making sure the declaration is initialized
+before its first use.

Questions? Ask the ACAA Technical Agent