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

--- ai05s/ai05-0054-2.txt	2007/12/13 04:39:37	1.3
+++ ai05s/ai05-0054-2.txt	2008/02/05 06:33:09	1.4
@@ -399,3 +399,168 @@
 that we don't have to care about it.
 
 ****************************************************************
+
+From: Erhard Ploedereder
+Sent: Sunday, February  3, 2008  6:29 PM
+
+My original intent to constrain legitimizing assignments to constants via
+the Rosen trick to constants of private type fell prey to generic contract
+issues, as the minutes already opined. (Or else I would have to impose so
+much load on implementing the variable-views-to-constants that the proposal
+would be flat on its face anyhow). Instead of revising AI-54 in ways that
+have not been discussed at a meeting, I am submitting a comment on the AI,
+since I have several issues with this AI-54/02.....
+
+The modification of 3.3(14) with its new notion of "updating a variable" may
+be technically opportune (and work), but it violates the "least surprise"
+principle of language design. "If the value of a variable changes by any
+operation, the variable has been updated" is something that 100% of computer
+scientists will sign as a true statement. It would no longer hold in
+Ada. Instead, the notion that "updating a variable" by assignment is
+dependent on the view of the type of a component whose value is changed is
+completely counter to the common interpretation of what updating a variable
+means. (Besides, I still am uncertain about all the ramification that are
+implied by "... the variable if its type is not a descendent of a partial
+view of a full or actual type"; I claim that max. 50% of the ARG and 0,x% of
+the Ada users understand the implications.)
+
+----
+Side remarks: 
+1. assuredly, this needs to say "object" instead of "variable" (or else the
+   intended effect for the modification of constants is not achieved);
+2. "its type" binds ambiguously both to "part" and "variable".
+-----
+
+I fell into this trap, too, since for the longest time, I then assumed
+that now assigning to said excepted parts would be allowed. But no, it 
+isn't: Assigment semantics also requires a variable view. Consider
+
+  procedure Foo(X: in T) is 
+  begin
+     null;
+     X.M.Gen.Z := 8; -- Rosen trick; X.M.Gen is an acc-to-var view of X
+     X.Z := 8; -- still illegal, since X is not a variable view
+  end Foo;
+
+and assume that Obj.M.Gen is always initialized such that it self-references
+Obj for any Obj. Assume further that all object-declarations in the universe
+carry a "constant" keyword.
+
+I had a large example prepared to show how the latter assignment causes 
+problems, but then I found out that it was illegal by this other rule in
+5.2. So, let's get this straight as per the revised 3.3(14):
+
+"The first assigment does not update X, although it changes the value of the
+Z component of X, but it updates Z. The second assignment would change the
+value of the Z component of X and thus update Z and X, but it is illegal to
+do so."
+
+Technically correct, but changing the same component by two different
+syntaxes has two different semantics? That is very interesting.  How does
+one teach that to anyone?
+
+Did you believe the first quoted statement? It actually is wrong and again,
+I fell into that trap. If X happens to be passed by value, then X.M.Gen.Z
+still refers to the Z component of the actual, while X.Z refers to the Z
+component of the formal copied from the actual. Only if X is passed by
+reference are the Zs the same (which is the case for the Rosen trick with
+limited or tagged types, but not necessarily any more if merely an
+access-to-variable of a constant has been obtained and squirreled away
+elsewhere, i.e., not in an access discriminant.  Note that the permission to
+use access-to-variable views on constant objects (as per the modified
+13.9.1(13)) is not restricted to limited or by-reference types. 
+Built-in-place extended results as initializations of constants are a case 
+in point. They need not be limited, yet any access value obtained in the
+process would be legitimate.
+
+On a secondary note, this AI, if approved, would make code optimization or
+any program analyses incorrect that assume equal values of a constant entity
+at all places after its declaration.  This is completely counter-intuitive
+and may require major compiler, analyzer and backend reworks, let alone
+rewiring of people's brains.
+
+For every one of these three reasons, a different way to legitimize the
+Rosen trick needs to be found if legitimizing is really desirable.
+(Personally, I find the conceptual and real costs of legitimizing the
+ idiom much too high in anything that I have seen so far.)
+
+note bene: I am not opposed to making the constant/variable view notion
+more explicit, as it is done with the 3.3(13) rewrite and with the add-on 
+after 3.3(14). I am merely opposed to have constant views that somehow can
+be perverted into lasting variable views (and dead set against perverting
+notions like "updating a variable" to special needs).  
+
+--- Another side remark ---
+If the add-on after 3.3(14) is kept in the final AI, it also needs
+to mention Pragma Volatile on constants as an exception.
+---------------------------
+
+Solutions ?:
+
+One possibility is to "upgrade" the access-to-variable modification of
+a constant to be a bounded error rather than erroneous: For subsequent
+uses of the constant either the assigned value or the old value is
+used.  While not a deterministic semantics, it gets rid of the
+erroneousness.  It also reflects the "actual events" of today, i.e.,
+the cacheing of constant values at compile- or runtime.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February  4, 2008  11:06 PM
+
+...
+Instead of revising AI-54 in ways that
+> have not been discussed at a meeting, I am submitting a comment on the AI,
+> since I have several issues with this AI-54/02.....
+> 
+> The modification of 3.3(14) with its new notion of "updating a variable" may
+> be technically opportune (and work), but it violates the "least surprise"
+> principle of language design.
+
+Huh? There is no modification to 3.3(14) in any latest version of AI05-0054-1
+or AI05-0054-2. And I don't see any way that the proposed change to 3.3(13)
+would have any effect. Ada has always had constant views of variable objects,
+so nothing new there.
+
+>"If the value of a variable changes by any operation, the variable has been
+> updated" is something that 100% of computer scientists will sign as a true
+> statement. It would no longer hold in Ada. Instead, the notion that
+> "updating a variable" by assignment is dependent on the view of the type
+> of a component whose value is changed is completely counter to the
+> common interpretation of what updating a variable
+> means. (Besides, I still am uncertain about all the ramification that are
+> implied by "... the variable if its type is not a descendent of a partial
+> view of a full or actual type"; I claim that max. 50% of the ARG and 0,x% of
+> the Ada users understand the implications.)
+
+This makes no sense. There is no wording like "... the variable if its type
+is not a descendent of a partial view of a full or actual type" in any of the
+AIs. What are you reading???
+
+...
+> note bene: I am not opposed to making the constant/variable view notion
+> more explicit, as it is done with the 3.3(13) rewrite and with the add-on 
+> after 3.3(14). I am merely opposed to have constant views that somehow can
+> be perverted into lasting variable views (and dead set against perverting
+> notions like "updating a variable" to special needs).  
+
+There is no "add-on after 3.3(14)" in any version of the AI that I've seen.
+Perhaps that is adding confusion where none is necessary...
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, February  4, 2008  11:40 PM
+
+I'll admit I didn't follow all of what Erhard
+wrote, but I agree that we should change the second
+sentence of 3.3(14) as follows:
+
+    ... The value of [a variable] {an object} is updated when
+    an assignment is performed to any part of the [variable]
+    {object}, or when an assignment is performed to an enclosing
+    object.
+
+****************************************************************
+