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

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

--- ai05s/ai05-0142-1.txt	2009/02/14 07:32:20	1.1
+++ ai05s/ai05-0142-1.txt	2009/02/17 05:36:36	1.2
@@ -208,4 +208,111 @@
 
 !appendix
 
+From: Bob Duff
+Sent: Sunday, February 15, 2009  11:04 AM
+
+> Add an "in out" mode to a function result. This would have a meaning 
+> as close to "in out" parameter passing as possible. In particular, the 
+> mode would mean that a (view of) a variable is returned. The view 
+> would have the accessibility of the function call, and could not be used
+> afterwards.
+
+It would indeed be nice to solve this problem.  It would also be a nice side
+effect to have a workaround for poeple who used return-by-ref in Ada 95, and
+get bitten by the incompatibility.
+
+(I realize I'm partly contradicting my earlier rant, but I really mean "if it's
+not complicated"!)
+
+A couple of other ideas that we might want to consider, for solving the same
+problem:
+
+Limited access types.  These would be restricted in some way such that you can't
+(easily) save away a copy and then have it become dangling.  This is similar
+to Randy and Dmitry's proposal, but makes the reference semantics explicit.
+I'm not 100% sure whether that's an advantage or a disadvantage.
+But I never likes Ada 95's return-by-ref feature, because I don't like implicit
+reference semantics.  (I just wish .all was spelled as it is in Pascal!)
+
+By the way, I handled a customer report a few days ago, from someone who was
+using Ada 95's return-by-ref precisely for this reason.  They were asking how
+to do the same thing in Ada 2005.
+
+A second idea is to have syntactic sugar for passing subprograms as parameters.
+If we make it sweet enough, Update_Element calls could be made readable.
+We'd have to allow the actual procedure to be anonymous, as in Lisp lambdas,
+and get rid of most boilerplate verbiage.
+
 ****************************************************************
+
+From: Christoph Grein
+Sent: Monday, February 16, 2009  3:25 AM
+
+This report Bob mentions was about my package Safe_Pointers which you can find
+at http://www.adaic.org/learn/ (a somewhat dated copy). For limited types, the
+"function Value (...) return Object" (return-by-reference) is illegal now and
+has to be replaced by "return access Object" or some such, which completely
+undermines the idea of a safe pointer.
+
+I know the Ada95
+  X: Object renames Value (Ptr);
+may also quietly become dangling but the scope of X is much smaller than that
+of an access object that may be stored away.
+
+I would love to see a function returning a kind of limited pointer that cannot
+be stored away, but can be dereferenced or used as a prefix for component
+manipulation like e.g.
+
+function Value (P: Safe_Pointer) return limited access Object; Value(Ptr).X := 5.0;
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 16, 2009  8:04 PM
+
+> I would love to see a function returning a kind of limited pointer 
+> that cannot be stored away, but can be dereferenced or used as a 
+> prefix for component manipulation like e.g.
+
+This idea has been raised before, but the idea of limited elementary types
+gives everyone hives.
+
+That's why I've proposed two ways to solve this problem, the proposal that you're
+commenting on and also the "call-level accessibility" that Bob didn't understand
+in his rant.
+
+The idea of the latter is that the accessibility of the returned point in something like:
+
+     function Value (P : Safe_Pointer) return access Object with Call_Level_Accessibility;
+
+is that of the function call. Thus it can't be assigned into any existing access object
+(it could be renamed); the intent is that it is *only* for dereference.
+
+I prefer getting rid of the "access" altogether (if we have pass-by-reference why shouldn't
+we have return-by-reference??), but either scheme will work. I'll do everything I can to
+ensure one or the other is adopted.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 16, 2009  11:13 PM
+
+...
+> A second idea is to have syntactic sugar for passing subprograms as 
+> parameters.
+> If we make it sweet enough, Update_Element calls could be made 
+> readable.
+> We'd have to allow the actual procedure to be anonymous, as in Lisp 
+> lambdas, and get rid of most boilerplate verbiage.
+
+You've mentioned this before, but I don't see how it could work. If you require
+writing enough stuff so that the result makes sense to a casual reader, it's still
+going to be a big glob of text (you can't get rid of the parameter decls or the
+begin and end). Sticking that in the middle of a call doesn't sound pleasant. I
+suppose you could make the parameters implicit, but then readability is going
+to be severely impacted, because you'd have objects that are referenced by never
+declared anywhere in the text (at least nowhere obvious). That doesn't sound
+very Ada-like.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent