CVS difference for ai12s/ai12-0322-1.txt

--- ai12s/ai12-0322-1.txt	2019/03/08 04:27:51	1.1
+++ ai12s/ai12-0322-1.txt	2019/03/08 06:20:23	1.2
@@ -1,4 +1,5 @@
-!standard 5.2.1(5/5)                                  19-03-07  AI12-0322-1/01
+!standard 4.9(15)                                  19-03-08  AI12-0322-1/02
+!standard 5.2.1(5/5)
 !class Amendment 19-03-07
 !status work item 19-03-07
 !status received 19-03-07
@@ -20,11 +21,16 @@
 
 !wording
 
+Add after 4.9(15):
+
+  * It is a target_name in an assignment_statement whose /variable_/name statically
+    denotes the entity;
+
 Change the redundant markings in 5.2.1(3/5):
 
    Redundant[If a target_name occurs in an assignment_statement A, the 
-   variable_name V of A is a complete context.] The target name Redundant[is a 
-   constant view of V,] having the nominal subtype of V.
+   variable_name V of A is a complete context.] The target name is a 
+   Redundant[constant] view of V, having the nominal subtype of V.
 
 Modify AARM 5.2.1(3.a/5):
 
@@ -32,7 +38,6 @@
   formally given in 3.3[; the nominal subtype follows from the equivalence 
   given below in Static Semantics]. 
 
-
 Replace 5.2.1 (5/5) with:
 
 Dynamic Semantics
@@ -48,10 +53,10 @@
    AARM Ramification: Use of a target_name can be erroneous if the 
    /variable_/name V is a discriminant-dependent component, and some
    other constituent of the expression modifies the discriminant 
-   governing V. While this is possible with assignment_statements that
-   don't use a target_name, it is more likely when using a target_name
-   as there is potentially more time between the evaluation of the name 
-   and the use of the value. See 3.7.2.
+   governing V. The assignment probably would be erroneous anyway,
+   but the use of a target_name eliminates the possibility that a
+   later evaluation of V raises an exception before any erroneous
+   execution occurs. See 3.7.2.
 
 !discussion
 
@@ -59,6 +64,10 @@
 with an explicit dynamic semantics defining what it means to evaluate a 
 target_name.
 
+We add a definition of statically denotes for the target_name, so that
+the anti-order-dependence rules of 6.4.1 can see through @. Presumably,
+there are other rules that would be helped as well.
+
 !ASIS
 
 [Not sure. It seems like some new capabilities might be needed,
@@ -585,6 +594,151 @@
 anti-order-dependence rules aren't intended to be complete anyway, but it 
 seems bad that introducing a short-hand makes this particular case legal when
 it otherwise would not be as it was judged to be too non-portable to allow.
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Thursday, March 7, 2019  10:53 PM
+
+It seems all we need to do is add a bullet after 4.9(14), saying that if the 
+target of an assignment statement statically denotes an object, then @ 
+statically denotes the same object.  That is, add after 4.9(15):
+
+  * It is a target_name in an assignment_statement whose /variable_/name statically
+    denotes the entity;
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Thursday, March 7, 2019  11:14 PM
+
+>> Replace RM 5.2.1 (5/5) with:
+>> 
+>> Dynamic Semantics
+>> 
+>> For the execution of an assignment_statement with one or more 
+>> target_names appearing in its expression, the /variable_/name V of 
+>> the assignment statement is evaluated first to determine the object 
+>> denoted by V, and then the expression of the assignment_statement is 
+>> evaluated with the evaluation of each target_name yielding a constant 
+>> view of the object denoted by V.  The remainder of the execution of 
+>> the assignment_statement is as given in subclause 5.2.
+> 
+> There's at least one problem with this: the Name Resolution Rules are 
+> marked Redundant because "the nominal subtype is determined by the 
+> equivalence rules given below".
+
+Oops.  We should make the part about the nominal subtype normative.  Hence, 
+replace 5.2,1(3/5) with:
+
+   [Redundant: If a target_name occurs in an assignment_statement A, the 
+   variable_name V of A is a complete context.] Each target_name in the 
+   assignment denotes a [Redundant: constant] view of V, having the 
+   nominal subtype of V.
+
+and modify 3.a/5:
+
+   Proof: The complete context rule is formally given in 8.6. The constant view 
+   rule is formally given in 3.3[; the nominal subtype follows from the 
+   equivalence given below in Static Semantics]. 
+
+...
+> I think we also want at least an AARM note about the erroneousness 
+> that can occur if the discriminant governing the target is changed; 
+> it's not at all obvious that such things can happen here.
+
+Sure they could.  Presuming the target of the assignment is a 
+discriminant-dependent component, a call on a function somewhere in the RHS 
+that assigns a value to the enclosing object with a different value of the 
+discriminant will render the assignment erroneous.  This is pretty much true
+whether or not there are target_names on the RHS, so I don't see it as a very 
+important point for this section.  The target_names aren't making it any 
+better or any worse.  Erroneous is erroneous!
+
+> Although really that a problem
+> with assignment statements as a whole -- they truly need such a note. 
+> (A cross-reference to 3.7.2(4) would be a big help, as it seems 
+> impossible to find that rule when it comes up in discussion. I would 
+> *never* have looked in 3.7.2, as the title of the clause says that it 
+> defines some attributes.)
+
+I could agree that assignment statements need such a note, but I don't think 
+a target_name makes things worse.
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Friday, March 8, 2019  12:04 AM
+
+...
+> > I think we also want at least an AARM note about the erroneousness 
+> > that can occur if the discriminant governing the target is changed; 
+> > it's not at all obvious that such things can happen here.
+> 
+> Sure they could.
+
+Certainly, I meant "not obvious to the causal reader". It's not obvious to me...
+
+> Presuming the target of the assignment is a discriminant-dependent 
+> component, a call on a function somewhere in the RHS that assigns a 
+> value to the enclosing object with a different value of the 
+> discriminant will render the assignment erroneous.  This is pretty 
+> much true whether or not there are target_names on the RHS, so I don't 
+> see it as a very important point for this section.
+
+But the only reason *I* thought of this is because Steve pointed it out back
+when target names were originally defined. Otherwise, I would never have 
+considered such a possibility, and since the rule involving is it buried in
+a bizarre place, I wouldn't have been able to figure it out. (How the heck 
+did you find that rule yesterday? I've looked for it for hours in the past 
+without finding it.)
+
+> The target_names aren't making it any better or any worse. 
+
+Actually, target names do make it worse (maybe not significantly).
+
+When you have:
+
+    T.F := T.F + Mods_T;
+
+there are two names here, and the second T.F is evaluated and the value is 
+used only once and (probably) used immediately. The time window for execution 
+to go erroneous is very short (and given that parallel execution is not 
+allowed for expression evaluation), nonexistent for this expression. If 
+Mods_T was called before T.F was evaluated, the evaluation of T.F will raise 
+an exception. In this case, there is no erroneous execution. Of course, the 
+other order is erroneous (because of the assignment into T.F). This is one 
+of the reasons Janus/Ada tries to call functions first in expressions, 
+regardless of how they're written (it also decreases register pressure).
+
+OTOH:
+
+    T.F := @ + Mods_T;
+
+There is a lot longer time between the time that @ is evaluated and the value 
+used, so there is a substantially greater time for the execution to become 
+erroneous -- the entire time that the expression is being evaluated.
+Using @, the expression will be erroneous regardless of the order, and a 
+friendly compiler can't help this.
+
+> Erroneous is erroneous!
+
+As I show above, not necessarily. :-) Maybe not a significant difference, but 
+the ordering in Janus/Ada has definitely helped debugging by preventing this 
+sort of erroneousness.
+
+> > Although really that a problem
+> > with assignment statements as a whole -- they truly need such a note. 
+> > (A cross-reference to 3.7.2(4) would be a big help, as it seems 
+> > impossible to find that rule when it comes up in discussion. I would
+> > *never* have looked in 3.7.2, as the title of the clause says that 
+> > it defines some attributes.)
+> 
+> I could agree that assignment statements need such a note, but I don't 
+> think a target_name makes things worse.
+
+Well, I wrote the note when I created the AI a few hours ago. We can decide on 
+Monday what to do with it.
 
 ***************************************************************