Lazy Evaluation [Side-Effects in Functions]

["Nick Roberts" <nickroberts@adaos.worldonline.co.uk>]

"Dmitry A. Kazakov" <dmitry@elros.cbb-automation.de> wrote in message
news:3be7a31d.1736453@News.CIS.DFN.DE...
above? The answer is no.
> ...
> P.S. A comment about computation order. I am not sure, but maybe it
> would be worth to think about introducing lazy parameters (Algol's by
> name). Ada already has them hard-wired in "and then" and "or else".
> The order lazy parameters are evaluated is obviously defined by the
> implementation of the subroutine, thus the above problems will
> disappear, or better to say, become the responsibility of the
> implementation. In your example "&" should have the second parameter
> lazy, so
>
>     Decode(Data(1..4)) & Decode(Data(5..8));
>
> would  mean: evaluate Decode(Data(1..4)); call "&", which internally
> calls Decode(Data(5..8)).

Briefly, the combination of lazy evaluation and side-effects, as such, would
be rather like the combination of a keg of TNT and a blowtorch.

The problem of side-effects in Ada would be largely solved by fixing the
order in which arguments are evaluated (e.g. strictly in the order they are
declared) for all functions. But this would be a pity in that it would
significantly hamper many compilers' efforts to optimise a lot of ordinary
code.

Lazy evaluation is an interesting idea. How about:

   function Sin (X: delay in Float) return Float;

where the 'delay' means that what is passed into Sin is an access value to a
temporary routine (X'Computation) that computes the required value of X. In
the body of Sin, a flag X'Computed is set False, and any reference to X
either: if X'Computed is False, causes a call to the temporary routine,
places the result into a temporary store for X, and sets X'Computed to True;
if X'Computed is True, retrieves the value of X from its temporary store.
Hey presto! Lazy evaluation. "and then" and "or else" could become first
class citizens.

The access value X'Computation would be subject to the same accessibility
rules as any other access (-to-subprogram) value. This business is, I guess,
closely related to that of lambdas etc.

I not actually saying that I like this idea, by the way, just that it's
intriguing.

--
Nick Roberts