Re: Lazy Evaluation [Side-Effects in Functions]

[dmitry@elros.cbb-automation.de (Dmitry A. Kazakov)]

On Tue, 6 Nov 2001 16:18:12 -0000, "Nick Roberts"
<nickroberts@adaos.worldonline.co.uk> wrote:

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

Yes. Then fixing the order does not solve another problem of
side-effects: when same objects are visible through different
arguments. The problem is of course in-out parameters per se. To the
list of their "crimes": LSP violation by generalization or
specialization; interesting effects in by-value vs. by-reference
parameter passing etc.

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

Something like this. Maybe pragma Volatile (X) should ensure that X is
computed each time it is accessed. Otherwise, X is computed only once.

Then (a crazy idea), it would be nice to have an ability for a lazy
parameter to evaluate discriminants (and type tags) separately from
the value. I do not know whether it possible, but it could solve the
"problem of measurement units". The type of dimensioned values will
have a discriminant specifying the unit of measure. Being static (in
most cases) it can be evaluated statically (for inlined subroutines),
thus units checks can be efficiently removed by the compiler.

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

It would be a dangerous stuff in right hands (:-)). Then I think to
get pragma Inlined working efficiently for subroutines with lazy
parameters would be not very easy.

Regards,
Dmitry Kazakov