Update-in-place assignment

Update-in-place assignment

[Bill Findlay]

On 18/06/2002 18:12, in article fSJP8.2780$ua4.1557@nwrddc03.gnilink.net,
"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote:

>> I prefer :=, and if I could change C I would change = to := and modify
>> all of the shorthand operators to look like Icon (:+= and the like).
> 
> Actually, the Icon augmented assignment operators look like this: "+:=".
> 
> I think that the Icon augmented assignment operators would be a worthwhile
> addition to Ada, not so much for optimizations but for readability. A smart
> compiler could probably optimize
> 
>   Whatchama_Callit.Thingy( Here ).Do_Hickey.Count :=
> Whatchama_Callit.Thingy( Here ).Do_Hickey.Count  + 1;
> 
> but then you're requiring the reader to visually confirm that the expression
> on the left of the assignment is the same as the expression on the left of
> the "+".
>

There is a case to be made for being able to specify that a component of an
expression being assigned is the same as the destination of the assignment.

Such a feature makes the code easier to read and to modify when the name of
the destination is verbose, as above; makes it easier for the compiler to
generate efficient code when it takes a nontrivial amount of code to
determine the address of the destination; and makes it crystal clear that
update-in-place is the programmer's intended semantics (the best reason).

The trouble with the C* "?=" operators, and the derivative proposals made in
this thread, is that they provide a very restricted subset of a much more
general facility.

E.g., and obviously, they would let me write   i -:= 1;   for   i := i - 1;
but they would provide no shorter way of expressing   i := 1 - i;

A way of achieving what the C* people say they want (i.e. expressive power),
is to have a notation (I'll use here the new reserved word "idem", but it
could be a special symbol instead) that may appear as an operand in the
right-hand side of an assignment statement, without restriction, and denotes
there the object named on the left-hand side.

E.g. we might have  i := idem -1;  or i := 1 - idem;
or even  x := 0.5 * (1.0 + a*idem);

What that does not give the C* people is maximal brevity.
The extra expressiveness should more than compensate.

Unlike the C* 'solution' it does not require the introduction of a new
assignment operator for each dyadic operator, and it supports the
non-commutative operators (and more general expressions) as effectively as
it does the commutative ones.
-- 
Bill-Findlay chez Blue-Yonder.co.uk ("-" => "")

Re: Update-in-place assignment

[Hyman Rosen]

Bill Findlay wrote:
> The trouble with the C* "?=" operators, and the derivative proposals made in
> this thread, is that they provide a very restricted subset of a much more
> general facility.
> 
> E.g. we might have  i := idem -1;  or i := 1 - idem;
> or even  x := 0.5 * (1.0 + a*idem);
> 
> What that does not give the C* people is maximal brevity.
> The extra expressiveness should more than compensate.

No. What it *also* does not give the C++ people is a place
to write the code to handle the operation efficiently!
The designer of a class can provide the ?= operators for
that class, and write the code to perform the operation.

With your suggestion, we have the expressiveness, but we
can't do anything with it. If the only goal is to avoid
mentioning a long name more than once, C++ has its version
of a renaming clause just like Ada does:

	double &d = myStruct.itsArray[7].itsPoints[15].z;
	d = (1 + d) / (1 - d);

Re: Update-in-place assignment

[Jacob Sparre Andersen]

Bill Findlay wrote:

> There is a case to be made for being able to specify that a component of an
> expression being assigned is the same as the destination of the assignment.
[...]
> E.g. we might have  i := idem -1;  or i := 1 - idem;
> or even  x := 0.5 * (1.0 + a*idem);

I like this idea, but we should (as Rosen points out) also
look at which opportunities it gives the programmer for
creating the corresponding implementations.

The least ugly construction I can come up with right now is
to allow the use of "idem" on an argument to specify that
even though it is formulated as a function, it is actually
just a procedure where the "idem" argument is "in out".

   function "*" (Left  : idem Matrix;
                 Right : in   Float) return Matrix;

should thus on the implementation side of things correspond
to

   procedure "+" (Left  : in out Matrix;
                  Right : in     Float);

But this doesn't contain any of the beauty of your
suggestion. Maybe it is best to leave it as an exercise for
the compiler to translate the expressions to the optimal
code.

Jacob
-- 
"There is a slight error in the exponent" - quantum vaacum
 mass is 10^35 times the total dark matter mass

Re: Update-in-place assignment

[Bill Findlay]

On 20/06/2002 23:35, in article 3D1258CF.3F4094DA@nbi.dk, "Jacob Sparre
Andersen" <sparre@nbi.dk> wrote:

> Bill Findlay wrote:
> 
>> There is a case to be made for being able to specify that a component of an
>> expression being assigned is the same as the destination of the assignment.
> [...]
>> E.g. we might have  i := idem -1;  or i := 1 - idem;
>> or even  x := 0.5 * (1.0 + a*idem);
> 
...
> 
>  function "*" (Left  : idem Matrix;
>                Right : in   Float) return Matrix;
> 
> should thus on the implementation side of things correspond
> to
> 
>  procedure "+" (Left  : in out Matrix;
>                 Right : in     Float);
> 
> But this doesn't contain any of the beauty of your
> suggestion. Maybe it is best to leave it as an exercise for
> the compiler to translate the expressions to the optimal
> code.
> 

That's my view. 
It's hardly rocket science to give optimal code in the simple cases
supported by update-in-place m/c instructions (where available) and you'll
be at least no worse off in more complex expressions than you would be
without idem.
--
Bill Findlay
bill@wfindlay.demon.co.uk (personal)
wf@dcs.gla.ac.uk (Glasgow University)
bfindlay@sli-institute.ac.uk (The SLI Institute)