Re: += in ada

["Robert I. Eachus" <rieachus@comcast.net>]

Russ wrote:

> I'll tell you exactly what the effect is: a compile error. And I must
> say that I am a bit surprised that this is not obvious to you. "+="
> would be a procedure, and my understanding of procedures in Ada is
> that they do *not* return a value.

Correct, IN ADA procedures do not return a value.

> Let's consider either possibility for operator precedence:
> 
>     x += ( y += 1 );
> or
>     ( x += y ) += 1;
> 
> The first grouping will not compile because the expression in parens
> returns no value. The second grouping will not compile because, as far
> as I know, a procedure cannot be an lhs (because it cannot return a
> reference, as in C++). Am I missing something here?

Yes. I understand the C (or C++) meaning perfectly.  But when you 
blithely talk about how Ada does not have augmented assignment and 
should, you may know perfectly well what you have in mind, but the ARG 
has got to understand things in gory detail to change the language.

To be blunt, in C, there are two operations: creating a value and an 
assignment.  All we are asking is that you define which is the effect, 
and which is the side effect.  You clearly don't answer because you 
don't understand the problem.  Assignment is special in Ada, very 
special.  It is not a value returning function or procedure.  It is a 
well defined sequence of events, one of which is the assignment 
operation.  Go read the ARM, or better AARM clause 5.2 headed Assignment 
Statements: http://www.adaic.org/standards/95aarm/html/AA-5-2.html.

Now, try to draft out a similar definition of what you want.  It can't 
be done, at least not based on what you have said here.  You clearly 
don't think that X :+ 1; (or whatever the final notation would be) is 
equivalent to X := X + 1;  You clearly want X evaluated ONCE, and for no 
temporaries to be involved.  From that I have to conclude that, if X is 
of a non-scalar type, such as an array--you have mentioned using this 
notation for vectors--assignment happens on a component by component 
basis.  Therefore if an exception occurs when evaluating the RHS, the 
value of the LHS can be inconsistant.  Fair enough, Ada 95 makes it 
easier to discuss such things.  But you had better clearly define which 
invariants hold, and which do not.

To my thinking the issue of exceptions when evaluating the LHS are the 
killer.  Clearly, you need the (original) value of X to evaluate the 
RHS, so that evaluation must come before any assignment operations, and 
before the addition operation.  But what if the value of X + 1 is 
inconsistant with X?  As a simple example, when X is an Integer, and X = 
Integer'Last, where do you expect the constraint check?  It can't happen 
  when you evaluate X, because that has to precede the evaluation of X + 
1.  So maybe you evaluate X twice?  Arrrggh!  We have completed the 
problematical loop.

Incidently, the procedural notation Inc(X); is well defined in ARM 
6.4.1.  But notice that there are explictly two cases.  If X is passed 
by value, there are two explicit assignment operations.  If X is passed 
by reference, there is a view conversion, and any assignment operations 
are distributed through the body of Inc.

You can now see, I hope, why I have been trying to convince you that 
adding this "simple" notation to Ada is far from simple.  On the other 
hand, Inc(X); or X++; or ++X; or whatever notation you choose is much, 
much simpler to add.  You (Russ) don't seem to be satisfied with that, 
and refuse to define what it is that Inc(X); lacks that is vital.


-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig