Re: "Subtract C, add Ada"

[jgv@swl.msd.ray.com (John Volan)]

lawnm@leeds.ac.uk (N. Mellor) writes:

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


Of course it isn't.  One way of tackling this kind of situation
without introducing new operators into the language is to exploit
renaming declarations:

	declare
	  Foobarzot : Whatever_Type renames Foo(Bar(Zot(Element+1)));
	begin
	  Foobarzot := Foobarzot + 1;
	end;

"Foobarzot" thus becomes a convenient local temporary alias for the
object otherwise known by the more cumbersome name of
"Foo(Bar(Zot(Element+1)))".  This makes the incrementing assignment
just as easy to read as any C-like alternative.  It also makes it clear
that the same object is being referenced on both sides of the
assignment, without needing to duplicate "Foo(Bar(Zot(Element+1)))"
(which is obviously error-prone).  Additionally, it makes it clear that
the computations that occur in "Foo(Bar(Zot(Element+1)))" should happen
only once, before incrementing the resulting object.

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


I couldn't aggree with you more.


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


Er, properly speaking, this should be something like:

    procedure Add (To : in out Whatever_Type; Addend : in Whatever_Type) is
    begin
      To := To + Addend;
    end Add;

And then it could be used as in:

    Add (To => Foo(Bar(Zot(Element+1))), Addend => 1);

In fact, the declare-block I wrote above could be viewed as an "inline"
equivalent to this procedure call.


>Any other thoughts?
>
>Nick Mellor
>Leeds


Hope this helps.

					-- John Volan

--------------------------------------------------------------------------------
 Me : Person :=
   (Name => "John G. Volan",  E_Mail_Address => "jgv@swl.msd.ray.com",
    Employer => "Raytheon",   Affiliation => "Enthusiastic member of Team-Ada!",
    Shameless_Controversial_Marketing_Slogan_For_Favorite_Language =>
      "<<<< Ada95: The World's *FIRST* Internationally-Standardized OOPL >>>>",
    Humorous_Language_Lawyerly_Disclaimer =>
      "These opinions are undefined by my employer, so using them would be "  &
      "totally erroneous ... or would that be a bounded error? :-) ");
--------------------------------------------------------------------------------