Version 1.5 of ai12s/ai12-0322-1.txt

Unformatted version of ai12s/ai12-0322-1.txt version 1.5
Other versions for file ai12s/ai12-0322-1.txt

!standard 4.9(16)          19-03-11 AI12-0322-1/04
!standard 5.2.1(4/5)
!standard 5.2.1(5/5)
!class Amendment 19-03-07
!status Amendment 1-2012 19-03-11
!status WG9 Approved 22-06-22
!status ARG Approved 10-0-0 19-03-11
!status work item 19-03-07
!status received 19-03-07
!priority Low
!difficulty Easy
!subject Equivalence for the target name symbol
!summary
Replace the equivalence for the target name symbol with some rules.
!problem
The equivalence for the target name symbol seems very complicated, verging on incomprehensible.
!proposal
(See Summary.)
!wording
Add after 4.9(16):
* It is a target_name (see 5.2.1) in an assignment_statement whose /variable_/name statically denotes some entity;
Modify AARM 5.2.1(3.a/5):
The complete context rule is formally given in 8.6. The constant view rule is formally given in 3.3; the nominal subtype {is a property taken from the target object as described below in Dynamic Semantics}[follows from the equivalence given below in Static Semantics].
Modify 5.2.1(4/5):
A target_name shall [only] appear {only} in the expression of an assignment_statement.
[Editor's note: Bob suggested this small rewording. Since the original AI is WG9-approved, the change has to go in some AI, and this one was handy and relevant.]
Replace 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 the target whose properties are otherwise identical to those of the view provided by V. The remainder of the execution of the assignment_statement is as given in subclause 5.2.
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 the component 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
We are replacing the old equivalence which was based on an implicit procedure, 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
No change is needed (this AI is not adding any new capabilities; AI12-0125-3 should describe the ASIS changes needed to support target name symbols).
!ACATS test
ACATS B- and C-Tests are needed to check that the new capabilities are supported.
!corrigendum 4.9(16)
Insert after the paragraph:
the new paragraph:
!corrigendum 5.2.1(0)
Insert new clause:
Just to force a conflict; the actual changes are found in the conflict file.
!appendix

From: Randy Brukardt
Sent: Wednesday, March 6, 2019  4:46 PM

Bob's RM review includes the following:

>5.2.1(5/5):
>[The variable_name is evaluated only once.] In particular, if a 
>target_name with nominal subtype S appears in the expression of an 
>assignment_statement A, then A is equivalent to a call on a local 
>anonymous procedure with the actual parameter being the variable_name 
>of A, where the local anonymous procedure has an in out parameter with 
>unique name P of subtype S, with a body being A with the variable_name 
>being replaced by P, and any target_names being replaced by the 
>qualified expression S'(P).

>That looks like Steve's handiwork.  ;-) Just say "A target_name denotes 
>the value of the variable_name (before the assignment). The 
>variable_name is evaluated only once."
>All this business about anonymous procedures is totally 
>incomprehensible.  Or at least move it to the AARM.
>
>Not sure "(before the assignment)" is necessary -- seems pretty obvious.
>
>Also, this is about "evaluation", so shouldn't it be under Dynamic 
>Semantics?

I don't know how to handle this one. My first inclination is to ignore it -- 
this topic was fairly throughly hashed over during the discussion of this AI.
But that doesn't seem to be appropriate. So let me explain this a bit and 
ruminate over options.

The reason for all of this babble is to clearly define what happens in various 
corner cases. Without it, we're leaving lots of semantics undefined, and there 
are questions about Legality, accessibility, finalization, and erroneousness 
that are left unanswered.

For instance, this model defines how @ is handled for the 
anti-order-dependence Legality Rules. It defines what happens if a 
discriminant governing the target is changed by the expression. It defines 
what happens to the value of the target itself is changed by the expression.
It defines how @ is finalized (it isn't). And probably a bunch of other things 
I haven't thought of (and perhaps that no one has thought of)).

We talked about defining all of these things explicitly, but it seems like it 
would require a lot of duplication and wording. And, unlike parens, we can't 
really get away without some definition, since there is no intuitive answer 
that applies (especially in corner-cases). Additionally, an equivalence rule
like this allows us to be certain that we can answer any weird case that Steve 
can come up with; explicit rules can't do that.

So, is there any other viable suggestion, or should I ignore this comment?
Or do I have to put it on the agenda??

***************************************************************

From: Tucker Taft
Sent: Wednesday, March 6, 2019  5:07 PM

I think should go on the agenda, but with a time-limited discussion.  It would 
*really* help if Bob and/or Steve could identify exactly what problems Steve's 
wording solves, i.e., what corner cases are not covered by Bob's wording.  If 
they are extremely rare, then a "To Be Honest" might be the right choice.

***************************************************************

From: Randy Brukardt
Sent: Wednesday, March 6, 2019  5:38 PM

> I think should go on the agenda, but with a time-limited discussion.

10 seconds? :-)

> It would *really* help if Bob and/or Steve could identify exactly what 
> problems Steve's wording solves, i.e., what corner cases are not 
> covered by Bob's wording.  If they are extremely rare, then a "To Be 
> Honest" might be the right choice.

I listed some of them in my original note:

(1) What happens if the target is modified by evaluating the expression?

    Glob : Natural := 0;

    function Side_Effect return Natural is
    begin
        Glob := Glob + 1;
        return 1;
    end Side_Effect;

    Glob := @ + Side_Effect;

Steve's wording says that Glob = 1 after this call, regardless of when 
Side_Effect is evaluated. Bob's wording leaves it unspecified (because it
leaves *everything* unspecified).

(2) What happens if the target is discriminant-dependent and the discriminant 
is changed?

    Glob.F := @ + Change_Glob;

Steve's wording says this is erroneous (by the rule that says doing this to a 
parameter is erroneous), Bob's wording says nothing.

(3) How is the anti-order-dependence rules enforced?

    Targ := @.F + Func_with_In_Out (@.F.all);

Steve's wording gives an unequivocal answer, no idea for Bob's (since it says 
nothing about anything).

***************************************************************

From: Steve Baird
Sent: Wednesday, March 6, 2019  5:41 PM

>> All this business about anonymous procedures is totally 
>> incomprehensible.  Or at least move it to the AARM.

Guilty as charged (and unrepentant).

We want the rules to correctly handle cases where the evaluation of the RHS 
modifies the LHS, as well as all the other issues that Randy mentioned.

An equivalence rule seemed like the way to go, for the reasons Randy 
described.

Originally, the idea was to use renaming semantics, so that

      LHS := Some_Func (@);

could be treated as

     declare
        @ : T renames LHS;
     begin
        @ := Some_Func (@);
     end;

But that didn't work if the LHS was something that was illegal to rename, 
such as
    Unconstrained_Variable.Discriminant_Dependent_Component

So we instead said that the assignment is equivalent to

    declare
      procedure Foo (Param : in out T) is
      begin
         Param := Some_Func (T'(Param));
      end;
    begin
      Foo (Lhs);
    end;

The point is that while you cannot rename
     Unconstrained_Variable.Discriminant_Dependent_Component
, you can pass it as an actual parameter.

I don't recall the reason for the S'(P) qualification mentioned in the 
current wording.

At the very least, Bob's suggestion would need to be augmented to state that 
the LHS name is evaluated before the RHS value.

***************************************************************

From: Randy Brukardt
Sent: Wednesday, March 6, 2019  5:57 PM

...
> I don't recall the reason for the S'(P) qualification mentioned in the 
> current wording.

I think it is a cutesy way to ensure that @ is a constant view. Since the 
parameter of the implicit subprogram is defined to be in out, it's a variable. 
I don't recall if there was a real issue with @ being a variable, or if we 
were just being pedantic.

***************************************************************

From: Steve Baird
Sent: Wednesday, March 6, 2019  6:07 PM

Sounds right.

***************************************************************

From: Bob Duff
Sent: Wednesday, March 6, 2019  6:22 PM

> I don't know how to handle this one. My first inclination is to ignore 
> it --

My intention for the RM review was that the editor would decide what to do --
agree or disagree with my suggestions.
Perhaps in rare cases bring it up for discussion.
But in any case, I'm not going to complain if you decide my suggestions are 
wrong.  I certainly don't want to have endless arguments about these things.

***************************************************************

From: Tucker Taft
Sent: Wednesday, March 6, 2019  6:27 PM

> I listed some of them in my original note:
> 
> (1) What happens if the target is modified by evaluating the expression?
> 
>    Glob : Natural := 0;
> 
>    function Side_Effect return Natural is
>    begin
>        Glob := Glob + 1;
>        return 1;
>    end Side_Effect;
> 
>    Glob := @ + Side_Effect;
> 
> Steve's wording says that Glob = 1 after this call, regardless of when 
> Side_Effect is evaluated. Bob's wording leaves it unspecified (because 
> it leaves *everything* unspecified).

This would still seem to depend on whether Glob is passed by copy or by 
reference, which is implementation-defined for cases where Glob is something 
like a Big_Num.  I agree for a by-copy type, the equivalence eliminates doubt
in this case, though perhaps a couple of added words would resolve this, and 
we could in fact eliminate the by-ref vs. by-copy uncertainty should we so 
choose.

In fact, if programmers use @ to be a short hand for simply writing the name 
again, they might be surprised the use of @ somehow eliminates an order 
dependence, and might not want to rely on that, but instead, would want to 
eliminate any possibility of such an order dependence.  I certainly didn't 
think of "@" as eliminating such bizarro order dependencies, and I don't see 
it as a valuable feature of "@."  If the semantics were that the order 
dependence still remained, I don't think anyone would complain.

> (2) What happens if the target is discriminant-dependent and the 
> discriminant is changed?
> 
>    Glob.F := @ + Change_Glob;
> 
> Steve's wording says this is erroneous (by the rule that says doing 
> this to a parameter is erroneous), Bob's wording says nothing.

This is still erroneous without Steve's circumlocutions, per 3.7.2(4):

   "The execution of a construct is erroneous if the construct has a 
   constituent that is a name denoting a subcomponent that depends on 
   discriminants, and the value of any of these discriminants is changed 
   by this execution between evaluating the name and the last use (within
   this execution) of the subcomponent denoted by the name. "

> (3) How is the anti-order-dependence rules enforced?
> 
>    Targ := @.F + Func_with_In_Out (@.F.all);

I presume you meant: "@.F.all + Func_With_In_Out(@.F.all);" unless you are 
doing "access type" arithmetic.

I'm not sure I see the problem here, since @ is a name which denotes something 
(namely the same thing denoted by Targ), and the rules of 6.4.1(6.5-6.25) are 
all compile-time checks, so only compile-time properties matter.

> Steve's wording gives an unequivocal answer, no idea for Bob's (since 
> it says nothing about anything).

Not sure I agree, though it is helpful to lay out these specific issues, so 
we can discuss them as a group (for 10 minutes, say ;-)

***************************************************************

From: John Barnes
Sent: Thursday, March 7, 2019  1:44 AM

Maybe this discussion reveals that @ was a bad idea after all.

***************************************************************

From: Tucker Taft
Sent: Thursday, March 7, 2019  2:45 AM

> Maybe this discussion reveals that @ was a bad idea after all.

Let's not go there! ;-)

I would suggest that perhaps we adopt an object-renaming equivalence rather 
than the implicit procedure-call equivalence, and simply say the rule 
disallowing certain renamings of discriminant-dependent components 
(RM 8.5.1(5/3)) is relaxed in this equivalence.  That seems pretty simple 
and matches the programmer's intuition better, I would argue.

Note that the only reason for 8.5.1(5/3) is to reduce the likelihood of the 
erroneousness identified in 3.7.2(4), given that an object renaming could be 
quite long-lived.  Given that "@" implies a much shorter extent for the 
(implicit) renaming, it is reasonable to suspend RM 8.5.1(5/3) and fall back 
on 3.7.2(4) to handle the possibility of side effects that change the value 
of a discriminant.

I think a renaming equivalence would be much easier to understand, and more 
closely matches the programmer's intuition about what "@" means.  It is also
somewhat easier to implement, I would claim, since it doesn't depend on 
faking the semantics of parameter passing, with all of the by-copy vs. 
by-reference shenanigans.  The renaming model is equivalent to a pure 
by-reference model, and will actually reduce the amount of implementation 
dependence.

***************************************************************

From: Richard Wai
Sent: Thursday, March 7, 2019  8:57 AM

> Let's not go there! ;-)
>
> I would suggest that perhaps we adopt an object-renaming equivalence 
> rather than the implicit procedure-call equivalence, and simply say the rule
> disallowing certain renamings of discriminant-dependent components (RM
> 8.5.1(5/3)) is relaxed in this equivalence.  That seems pretty simple 
> and matches the programmer's intuition better, I would argue.

Hear, hear! 

> Glob : Natural := 0;
> 
>   function Side_Effect return Natural is
>   begin
>       Glob := Glob + 1;
>       return 1;
>   end Side_Effect;

>   Glob := @ + Side_Effect;

In this example, I find it honestly inconceivable that the last statement 
would somehow not be _exactly_ equivalent to "Glob := Glob + Side_Effect;". 
That is the whole point of '@', and I cannot imagine a programmer who would 
not see it that way. It is a simple concept too, no need to make it do crazy
things, it's ugly enough as it is!

***************************************************************

From: Steve Baird
Sent: Thursday, March 7, 2019  1:13 PM

> I think a renaming equivalence would be much easier to understand, and more 
> closely matches the programmer's intuition about what "@" means.

Agreed. The objection to that was that, without the rules relaxation you 
propose, it would cause certain reasonable uses of "@" to be illegal.
I agree that the rules relaxation you propose is another good solution to the 
problem.

And it makes it clear that the LHS is evaluated before we begin evaluation of 
the RHS.

***************************************************************

From: Randy Brukardt
Sent: Thursday, March 7, 2019  2:04 PM

...
> That seems pretty simple 
> and matches the programmer's intuition better, I would argue.

This seems like a reasonable approach to be, subject the next oddity raised 
by Steve. ;-)

I presume that we would be renaming a qualified expression, so as to preserve 
the requirement that @ is a constant view.

Could you propose some wording along these lines so I can write something up 
for the meeting? Preferably before the deadline, along with your RM review and 
the rewording of AI12-0282-1. :-) [As always, tell me if you're going to be a 
bit late, just so I'm not surprised by late submissions.]

***************************************************************

From: Bob Duff
Sent: Thursday, March 7, 2019  4:42 PM

> And it makes it clear that the LHS is evaluated before we begin 
> evaluation of the RHS.

I admit that things are not as simple as I implied in my note to Randy.  I 
expected Randy to "take it or leave it", not start a long discussion.  But I
do think the renaming suggestion from Tucker is rather less arcane.

***************************************************************

From: Randy Brukardt
Sent: Thursday, March 7, 2019  9:20 PM

> I admit that things are not as simple as I implied in my note to 
> Randy.  I expected Randy to "take it or leave it", not start a long 
> discussion.

I couldn't decide how to handle the comment. I had thought about it 
periodically for parts of three days, it was starting to drive me nuts, and 
concluded "if in doubt, ask the group" (especially better than obsessing over
something not very important).

> But I do think the renaming
> suggestion from Tucker is rather less arcane.

...which is why I couldn't decide on what to do. You had a good point, just 
not a good replacement. And I'm trying not to write the *whole* standard by 
myself.

***************************************************************

From: Tucker Taft
Sent: Thursday, March 7, 2019  4:38 PM

Here is an attempt to simplify the handling of target_name (aka "@").  I 
abandoned using an equivalence completely, because the dynamic semantics 
are so straightforward.

-------

!subject Define target_name without recourse to an implicit procedure
  
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.

!discussion

We are replacing the old equivalence which was based on an implicit procedure, 
with an explicit dynamic semantics defining what it means to evaluate a 
target_name.

***************************************************************

From: Randy Brukardt
Sent: Thursday, March 7, 2019  9:44 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".

It's weird and usually not the case that we define Static Semantics in Dynamic 
Semantic rules; that matters for properties like static accessibility and 
aliasedness. All of the cases I can think of are rare corner cases, though.
(Yes, @'Access is possible, but not very likely.)

I'm not sure about the anti-order-dependence rules, though, and particularly 
"known to denote the same object" and it's cousin. These depend on "statically
denote", so one has to ask if '@' statically denotes anything.
Maybe it doesn't matter enough, as those rules aren't expected to catch 
everything.

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. 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.)

***************************************************************

From: Randy Brukardt
Sent: Thursday, March 7, 2019  10:16 PM

> I'm not sure about the anti-order-dependence rules, though, and 
> particularly "known to denote the same object" and it's cousin. These 
> depend on "statically denote", so one has to ask if '@' statically 
> denotes anything.
> Maybe it doesn't matter enough, as those rules aren't expected to 
> catch everything.

To expand on this a bit. The rule in question is 6.4.1(6.6/3):

* both names statically denote the same stand-alone object or parameter; or

This is clearly False for "@", at least as it stands: it doesn't statically 
denote anything (it can't do that in general in any case). Skimming the rest
of it, it seems we were trying to avoid anything dynamic in the names, so 
just allowing identical names to match wouldn't work in every case (think 
function call), so this would need a complex definition to trigger.

So my example from yesterday:

    Targ := @.F.all + Func_with_In_Out (@.F.all);

is legal using @ as defined in your AI, but illegal as defined in with 
Steve's anonymous procedure (or even with a renames sans Legality, there's 
special rules for that case) and definitely if one wrote it without using @:

    Targ := Targ.F.all + Func_with_In_Out (Targ.F.all);

One could argue that this isn't particularly important as the 
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: Randy Brukardt
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.

***************************************************************

From: Tucker Taft
Sent: Friday, March 8, 2019  8:18 AM

> ...
> 
>> 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.

All good points.
 
>>> 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.

Sounds good.

***************************************************************


Questions? Ask the ACAA Technical Agent