Re: "Subtract C, add Ada"

[smize@Starbase.NeoSoft.COM (Samuel Mize)]

The attached discussion of "self-referencing assignments" (I like
the term -- is it a standard term?) raises some points for me.

Yes, there should be a clearer method for self-referencing
assignments.  The usual argument (that I've seen) for the 
C operators +=, *=, etc., is that the code won't have to do
the same dereference/index/etc. series twice.  This is dumb;
this is what the optimizer should do.  BUT your point about
readability is very true.  The action "modify this value
somehow" is a common task.

Of course, the C operators are prone to typos.

Also, you can only do a simple calculation (one multiply,
one add...).

It seems to me that something more general would be useful,
along the lines (NOT THIS SYNTAX, THIS IDEA):

     foo( bar( zot( element + 1))) := <left> * ( <left> + 3 );

Question for the net: how much were self-referencing assignment
operators, and and algebraic ifs (the ?: operator pair) considered
for Ada83 and Ada95 (1).  Are they discussed in the Rationales,
or where would I find discussion of the reason for their omission
from Ada?  (I'll be looking through the Rationales for this, but
if you know where to look it will help me.)

Samuel Mize - smize@starbase.neosoft.com

(1) YES!  THAT'S RIGHT!  NINETY-*FIVE*!  I GOT THE RIGHT NUMBER THIS
    TIME, OK?      :-)      =8-p

In article <lawnm.33.00146988@leeds.ac.uk>,
N. Mellor <lawnm@leeds.ac.uk> wrote:
>In article <3fode9$dap@soleil.uvsq.fr> hebert@prism.uvsq.fr (Renaud HEBERT) writes:
...
>>... On the other hand what do you think about the operators += *= ...
>>They make thing shorter AND easier to read, a += 5; means exactly add 5 to a.
>>So don't you think that these construct have their place in Ada.
>
>This seems a valid point to me, particularly because += 
>simplifies and clarifies expressions, particularly complex ones. I 
>don't think there'd be much disagreement over this one, for example:
>
>foo( bar( zot( element + 1))) = foo( bar(zot( element + 1))) + 1;
>
>foo( bar( zot(element + 1))) += 1;
>
>The second clearly saves on mistakes and makes the whole line more readable. 
>To check the first, you need to do a mechanical, lexeme by lexeme comparison 
>of the two array references to check that they're the same-- not a great score 
>in the readability stakes. This is a clear example of C shorthand being 
>superior, in some situations, in some respects, to Ada's straightforwardness. 
>It isn't the whole story, of course.
>
>BUT...self-referencing assignments are a very common idiom in just about any 
>language, and it's only right that we should at least discuss ways of 
>expressing them elegantly. Though on the whole C/C++ haven't seen me for dust, 
>I do miss +=, -= and algebraic ifs (the ?: operator pair). All of these can 
>usefully reduce complexity in very busy and convoluted bits of code.
>
>Of course, there are other good reasons for not having these goodies. 
>One is that they're not essential, and too many operators can increase the 
>complexity of the language disastrously. One of the problems with C is its
>plethora of operators and the consequent complexity of the operator precedence 
>rules. Add to that C's blurring of the distinction between statements and 
>expressions and you have serious readability problems, whether for novices or 
>experts.
>
>The bottom line is that it's simple to write an Ada procedure which safely 
>adds or subtracts its second argument from its first, which can be defined as 
>an in out parameter:
>
>procedure self-add(in out var, in expression) is
>  var := var + expression;
>end self-add;
>
>and use it as in
>
>self-add( foo( bar( zot( element + 1))) , 1);
>
>
>Any other thoughts?
>
>Nick Mellor
>Leeds