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

Differences between 1.5 and version 1.6
Log of other versions for file ai05s/ai05-0144-1.txt

--- ai05s/ai05-0144-1.txt	2009/06/03 00:07:15	1.5
+++ ai05s/ai05-0144-1.txt	2009/11/04 06:26:38	1.6
@@ -202,7 +202,7 @@
 (the right operand is still (C => 1), but now the left operand is (C => 2), and O1.C
 is still 2 afterwards).
 
-This is usually used as a reason to not allow *in out* parameters on functions.
+This is usually used as a reason to disallow *in out* parameters on functions.
 If you have to use access parameters, then the expression is:
 
     if F3(O1) = F3(F1(O1'access)) then
@@ -317,7 +317,7 @@
 
 Survey of solutions
 
-It fairly obvious that that order dependencies are a problem in Ada, and
+It is fairly obvious that order dependencies are a problem in Ada, and
 have been getting worse with each version of the language (even without
 *in out* parameters in functions). Moreover, it has been used as the
 primary reason for leaving something natural and useful (*in out* parameters
@@ -356,6 +356,10 @@
 Param <- <expr> for an *in* parameter (this includes access); Param -> <expr>
 for an *out* parameter; and Param <-> <expr> for an *in out* parameter.
 
+[It has been pointed out that a very early version of Ada used ":=", "=:",
+and ":=:" for this purpose. The author find those too weird to contemplate,
+and in any case doesn't change the argument any.]
+
 However, for compatibility, old code that don't use the symbols would
 have to be allowed. That's especially bad because the symbol for ordinary
 named parameters (=>) looks like the symbol for an *out* parameter; while it
@@ -383,6 +387,10 @@
 parameters and making it optional elsewhere. That might placate *in out*
 parameter opponents, but otherwise doesn't seem to do much for the language.
 
+Defining a Restriction here might help with new programs by enforcing style
+(although Restrictions really are terrible for enforcing style alone, since they
+also apply to the runtime which probably was built with a completely different
+style guide), but even that would not do much to help existing code.
 
 
 
@@ -406,13 +414,15 @@
 
      if F2(O1) = (C => 1) then
 
-would not be. Obviously, this is too strict. Amazingly, it also not strict
+would not be. Obviously, this is too strict. Amazingly, it is also not strict
 enough:
 
      Some_Array(F3(O1)) := F2(O1);
 
 would be allowed. (An assignment statement is *not* an expression!)
 
+So, correcting some of the deficiencies:
+
    A call of a function with an *in out* parameter must be the only call in
    an expression or statement;
    If a call of a function with an *in out* parameter is the source expression
@@ -499,7 +509,7 @@
 
 So we could modify the definition of "potentially the same object" to:
 
-Two objects are considered to be "potentially the same object" one has the type
+Two objects are considered to be "potentially the same object" if one has the type
 of a part of the other, or one has a part whose type is a partial view, unless:
    * one object is part of a stand-alone object, and the other object is part
      of a different stand-alone object;
@@ -613,7 +623,7 @@
 
 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.
+them), array components (we won't try to determine if they are the same), and so on.
 
 These are the rules proposed in the !wording section above.
 

Questions? Ask the ACAA Technical Agent