CVS difference for ais/ai-00323.txt

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

--- ais/ai-00323.txt	2003/03/04 04:56:23	1.2
+++ ais/ai-00323.txt	2006/01/10 22:17:46	1.3
@@ -1997,3 +1997,227 @@
 
 ****************************************************************
 
+From: Pascal Leroy
+Sent: Tuesday, January 10, 2006  6:50 AM
+
+[Replying to private mail from Tucker Taft - ED]
+
+...
+
+>      I also am
+>      not particularly comfortable with being tagged as the sole
+>      holdout on "out" parameters for functions.
+
+But you are ;-)
+
+>      When we discussed
+>      this in the past in a more open forum than an ARG meeting,
+>      there were many voices in favor of preserving the in-parameter-only
+>      rule.  It is conceivable that I am the only ARG member who
+>      is still sympathetic with that rule, but I wasn't actually
+>      aware of that (not that that changes my view, of course ;-).
+
+I am not sure what forum or what discussion you refer to, but it would be
+interesting to hear rational justification from real users. The reason why I am
+frustrated by this topic is that it has never been discussed in depth, although
+it keeps cropping up from time to time in unrelated discussions (the only time
+it was addressed in an ARG meeting was in Padua, and we didn't spend 10 minutes
+on it).  My recollection from the Padua meeting is that many people were
+concerned about destabilizing the language or compilers.  But it turned out
+that over time we became bolder and made other changes that are bigger and more
+complex.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, January 10, 2006  7:31 AM
+
+...
+> I am not sure what forum or what discussion you refer to, but it would be
+> interesting to hear rational justification from real users.
+
+I believe it was discussed in depth during the Ada 9X
+process.  It may be that was the last time there was
+a thorough airing of the issues.  Those heavily involved
+in this earlier discussion remember it as being very
+contentious, and probably avoided it during the
+Ada 200Y process for that reason.
+
+> ... My
+> recollection from the Padua meeting is that many people were concerned
+> about destabilizing the language or compilers.  But it turned out that
+> over time we became bolder and made other changes that are bigger and more
+> complex.
+
+It might be worth trying to find the old Ada 9X notes
+on this topic some day...  Implementation issues were
+only a part of the argument -- the big part had to do
+with the likelihood of code being harder to read, understand,
+verify, and debug.  Access parameters were the Ada 9X
+solution to both kinds of issues, because they allowed
+pass-by-reference for "out" parameters (pass-by-copy-out
+was felt to be more of a burden in the middle of an
+expression), and they made the use highly visible,
+due to the need for "aliased" and "'Access".
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, January 10, 2006  9:55 AM
+
+I guess it would be better to discuss this topic around a bottle of wine,
+however...
+
+> ...the big part had to do
+> with the likelihood of code being harder to read, understand,
+> verify, and debug.
+
+I have some sympathy with this, but my view is that at the moment we have
+the worst of both worlds:
+
+1 - The absence of out parameters for functions is a constant annoyance,
+and it makes the language more awkward/less powerful than it should be.  I
+don't think that I write particularly disgusting code, but I suspect that
+every other day I run into a situation where I wish I could have a
+function with an out parameter.  I can invariably find work-arounds, but
+they are unnecessarily contrived, and many times they only work because my
+program (a compiler) is sequential.
+
+2 - Functions are not "safe" or easy to debug/read/understand.  Basically
+the rule is that you can do all the nastiness you wish as long as you
+don't document them in the profile.  Side effects, or modifications
+through access parameters do not make things particularly easy to
+understand, and I would much prefer to see "in out" in the specification
+than to find that some function has a side effect because it needs to
+updates a cache.
+
+This is why I would love to have two distinct kinds of functions: those
+that can do anything, and those that are pure mathematical functions (John
+amusingly called them whores and virgins, but I don't think we would want
+to adopt this terminology as official technical terms).  That way the
+programmer could choose between powerful/flexible and safe/readable, and
+of course make the choice on a case-by-case basis.
+
+> Access parameters were the Ada 9X
+> solution to both kinds of issues, because they allowed
+> pass-by-reference for "out" parameters (pass-by-copy-out was
+> felt to be more of a burden in the middle of an expression),
+> and they made the use highly visible, due to the need for
+> "aliased" and "'Access".
+
+I bought this story 10 years ago but I lost my illusions after trying to
+use the damned language.  There is a category of problems (notably in the
+OOP world) where access parameters work very well, and this is one of the
+reasons why I was all in favor of making them more powerful in Ada 2005.
+But if what you are trying to do is have an in out Integer, access
+parameters are a big pain in the b*tt.  "Access" and "aliased" stick out
+like two sore thumbs, and the readability of the source code is
+considerably degraded.  Not to mention that many people probably go for
+Unchecked_Access to circumvent the accessibility rules, so they run the
+risk of being bitten by dangling pointers.
+
+The bottom line is that you don't help the programmer by making it hard to
+solve a problem that pops up all the time.  You help the programmer by
+giving them a wide range of tools so that they can choose the most
+appropriate for a given problem.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 10, 2006  1:12 PM
+
+> I guess it would be better to discuss this topic around a bottle of wine,
+> however...
+
+The more bottles, the better. :-) :-)
+
+Tucker said:
+
+> I believe it was discussed in depth during the Ada 9X
+> process.  It may be that was the last time there was
+> a thorough airing of the issues.  Those heavily involved
+> in this earlier discussion remember it as being very
+> contentious, and probably avoided it during the
+> Ada 200Y process for that reason.
+
+The problem with depending on this is that it is a 15-year old discussion. Much
+has changed about Ada, and the world, since then. Moreover, Pascal is proposing
+adding a real, checked Pure function, which I think would mitigate some of the
+concerns (it would *more* possible to write safe functions than it is now).
+
+Pascal said:
+
+> > ...the big part had to do
+> > with the likelihood of code being harder to read, understand,
+> > verify, and debug.
+>
+> I have some sympathy with this, but my view is that at the moment we have
+> the worst of both worlds:
+>
+> 1 - The absence of out parameters for functions is a constant annoyance,
+> and it makes the language more awkward/less powerful than it should be.  I
+> don't think that I write particularly disgusting code, but I suspect that
+> every other day I run into a situation where I wish I could have a
+> function with an out parameter.  I can invariably find work-arounds, but
+> they are unnecessarily contrived, and many times they only work because my
+> program (a compiler) is sequential.
+>
+> 2 - Functions are not "safe" or easy to debug/read/understand.  Basically
+> the rule is that you can do all the nastiness you wish as long as you
+> don't document them in the profile.  Side effects, or modifications
+> through access parameters do not make things particularly easy to
+> understand, and I would much prefer to see "in out" in the specification
+> than to find that some function has a side effect because it needs to
+> updates a cache.
+>
+> This is why I would love to have two distinct kinds of functions: those
+> that can do anything, and those that are pure mathematical functions (John
+> amusingly called them whores and virgins, but I don't think we would want
+> to adopt this terminology as official technical terms).  That way the
+> programmer could choose between powerful/flexible and safe/readable, and
+> of course make the choice on a case-by-case basis.
+
+Exactly.
+
+One middle ground alternative would be to allow "in out" only on by-reference
+types (in this case, it is identical to "not null access"). But that seems a
+bit goofy, and contract issues would prevent much use in generics.
+
+So I think it is best to eliminate the silly restriction.
+
+> > Access parameters were the Ada 9X
+> > solution to both kinds of issues, because they allowed
+> > pass-by-reference for "out" parameters (pass-by-copy-out was
+> > felt to be more of a burden in the middle of an expression),
+> > and they made the use highly visible, due to the need for
+> > "aliased" and "'Access".
+>
+> I bought this story 10 years ago but I lost my illusions after trying to
+> use the damned language.  There is a category of problems (notably in the
+> OOP world) where access parameters work very well, and this is one of the
+> reasons why I was all in favor of making them more powerful in Ada 2005.
+> But if what you are trying to do is have an in out Integer, access
+> parameters are a big pain in the b*tt.  "Access" and "aliased" stick out
+> like two sore thumbs, and the readability of the source code is
+> considerably degraded.  Not to mention that many people probably go for
+> Unchecked_Access to circumvent the accessibility rules, so they run the
+> risk of being bitten by dangling pointers.
+
+Exactly again. Indeed, I was one of the people that was firmly against in out
+parameters for functions in Ada 95. But I've found that that it makes a lot of
+things harder/uglier. Moreover (unlike Pascal), I try hard to avoid visible
+access types in OOP -- they're not usually needed (except for this stupid
+case), and cause accessibility issues where there would need to be none. (Claw
+has very few visible access types; of course there are a lot of them under the
+covers.)
+
+> The bottom line is that you don't help the programmer by making it hard to
+> solve a problem that pops up all the time.  You help the programmer by
+> giving them a wide range of tools so that they can choose the most
+> appropriate for a given problem.
+
+This is one of the best summaries I've heard on the topic. Can I add it to the
+AI for future reference?
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent