CVS difference for ai05s/ai05-0144-2.txt

--- ai05s/ai05-0144-2.txt	2010/04/06 00:41:41	1.5
+++ ai05s/ai05-0144-2.txt	2010/04/13 02:50:50	1.6
@@ -1,10 +1,11 @@
-!standard 6.02 (11)                                 10-02-24  AI05-0144-2/03
+!standard 6.02 (11)                                 10-04-12  AI05-0144-2/04
 !class Amendment 09-06-07
+!status ARG Approved  5-0-4  10-02-26
 !status work item 09-06-07
 !status received 09-06-07
 !priority High
 !difficulty Hard
-!subject Detecting dangerous order dependencies
+!subject Detecting dangerous order dependences
 
 !summary
 
@@ -12,13 +13,13 @@
 
 !problem
 
-Ada does not define the order of evaluation of parameters in calls. This opens up
-the possibity that function calls with side-effects can be non-portable. The
-problem gets worse with "in out" and access parameters, as proper evaluation
-may depend on a particular order of evaluation.
+Ada does not define the order of evaluation of parameters in calls. This opens
+up the possibity that function calls with side-effects can be non-portable. The
+problem gets worse with "in out" and access parameters, as proper evaluation may
+depend on a particular order of evaluation.
 
 Arguably, Ada has selected the worst possible solution to evaluation order
-dependencies: it allows such dependencies (by not specifying an order of evaluation),
+dependences: it allows such dependences (by not specifying an order of evaluation),
 does not detect them in any way, and then says that if you depend on one (even if
 by accident), your code will fail at some point in the future when your compiler
 changes.
@@ -91,7 +92,7 @@
 If a call C has two or more parameters of mode in out or out that
 are of an elementary type, then the call is legal only if:
 
- *  For each name N of an that is passed as a parameter of
+ *  For each name N that is passed as a parameter of
     mode in out or out to the call C, there is no other name among the
     other parameters of mode in out or out to C that is known to denote the
     same object.
@@ -660,8 +661,12 @@
 > like the various examples by making it portable.
 
 I doubt if I'll convince anyone, but I think that's a bogus argument.
-People do, in fact, depend on eval order all the time, either by accident, or because they don't know the language rules.  And there's nothing any language definition can say to stop it.  A language definition can say, "It is considered bad style to depen
d on evaluation order (of...).
-Don't do that."  That would have just as much effect as leaving the order undefined -- i.e. it puts people on notice, but doesn't entirely stop the problem.
+People do, in fact, depend on eval order all the time, either by accident, or
+because they don't know the language rules.  And there's nothing any language
+definition can say to stop it.  A language definition can say, "It is considered
+bad style to depend on evaluation order (of...). Don't do that."  That would
+have just as much effect as leaving the order undefined -- i.e. it puts people
+on notice, but doesn't entirely stop the problem.
 
 >... Moreover, Ada compilers have been using this  flexibility for
 >decades; trying to remove it from compilers (particularly  from
@@ -673,9 +678,10 @@
 > Another option would be to increase the visibility of parameters with
 > side-effects. This sounds somewhat appealing (after all, it seems to
 > be the basis on which access parameters are deemed OK and *in out*
-> parameters are not). One possibility would be to add ordering symbols to named notation:
-> Param <- <expr> for an *in* parameter (this includes access); Param ->
-> <expr> for an *out* parameter; and Param <-> <expr> for an *in out* parameter.
+> parameters are not). One possibility would be to add ordering symbols to named
+> notation: Param <- <expr> for an *in* parameter (this includes access); Param
+> -> <expr> for an *out* parameter; and Param <-> <expr> for an *in out*
+> parameter.
 
 Ada 80 (or thereabouts) used the symbols :=, =:, and :=: for this.
 I suggest you use this notation (before shooting it down below).
@@ -694,9 +700,11 @@
 > the prefix and access issues are not so easily explained away.
 > Additionally, putting the mode into calls in some way makes
 > maintenance of programs harder: changing the mode of a call is going
-> to make many calls illegal, while today most calls will remain legal (all will if the mode is changed from "in out" to "in").
+> to make many calls illegal, while today most calls will remain legal (all will
+> if the mode is changed from "in out" to "in").
 
-I think that last part is bogus -- it's like saying the full coverage rules for aggregates make maintenance harder.
+I think that last part is bogus -- it's like saying the full coverage rules for
+aggregates make maintenance harder.
 
 > Another syntax suggestion that was made recently was to (optionally)
 > include the parameter mode as part of the call. That would look something like:
@@ -710,11 +718,12 @@
 >
 > One could imagine requiring the syntax for calls of functions with *in
 > out* parameters and making it optional elsewhere. That might placate
-> *in out* parameter opponents, but otherwise doesn't seem to do much for the language.
+> *in out* parameter opponents, but otherwise doesn't seem to do much for the
+> language.
 
-If we were to do any of the above "marking [in]out params" syntax, we should also define
-a Restriction that forces it on all calls (not 'in' params, of course).
-Worth mentioning, even though we're not going this route.
+If we were to do any of the above "marking [in]out params" syntax, we should
+also define a Restriction that forces it on all calls (not 'in' params, of
+course). Worth mentioning, even though we're not going this route.
 
 > Finally, we come to some sort of legality rules and/or runtime checks
 > for preventing such order dependencies. It is important to note that
@@ -723,7 +732,8 @@
 > an annoyance, but surely not as bad as the current ticking time-bomb.
 >
 > The easiest option is to blame all of the problems on functions with
-> *in out* parameters and make them stand alone. The rule would be something like:
+> *in out* parameters and make them stand alone. The rule would be something
+> like:
 >
 >    A call of a function with an *in out* parameter must be the only call in
 >    an expression.
@@ -743,10 +753,10 @@
 
     Blah : T := Func(...);
 
-which is one of the more useful cases.  Especially when T is something like String.
+which is one of the more useful cases.  Especially when T is something like
+String.
 
->...Amazingly, it also not strict
-> enough:
+>...Amazingly, it also not strict enough:
 >
 >      Some_Array(F3(O1)) := F2(O1);
 >
@@ -778,7 +788,8 @@
 ...
 > Such rules would only reject calls where it is clear that parts of the
 > same object are involved. That eliminates the complications of private
-> types (we won't look in them), arrays (we won't try to determine if they are the same), and so on.
+> types (we won't look in them), arrays (we won't try to determine if they are
+> the same), and so on.
 
 "arrays" --> "array components", I think you mean.
 
@@ -790,11 +801,12 @@
 > expression to contain only a single function call unless all of the functions are *strict*.
 
 I don't think "strict" is the right term, here.  In computer science, "strict"
-means "arguments are evaluated at the call", as opposed to "lazy" and "non-strict" (which
-are almost, but not quite the same thing -- Haskell is non-strict), and "call by name".
+means "arguments are evaluated at the call", as opposed to "lazy" and
+"non-strict" (which are almost, but not quite the same thing -- Haskell is
+non-strict), and "call by name".
 
-I'd consider extending "pure" to this concept.  Or else don't define a term, just talk about
-"such functions" in this part.
+I'd consider extending "pure" to this concept.  Or else don't define a term,
+just talk about "such functions" in this part.
 
 [Editor's note: I tried that and people hated it. A new term seemed better. Doesn't
 matter, because we're not doing any of this.]