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.
***************************************************************
Questions? Ask the ACAA Technical Agent