Re: [Caml-list] Evaluation Order

[Dave Mason <dmason@sarg.Ryerson.CA>]

>>>>> On Sun, 10 Jun 2001 19:59:11 +0200 (MET DST), Damien Doligez <Damien.Doligez@inria.fr> said:

> The original argument about optimizations is still as valid as it
> ever was.  The real problem is that there is a conflict between
> left-to-right evaluation order and currying.  Consider the
> expression:

>    f e1 e2 e3

> It only looks like the application of f to 3 arguments.  In reality,
> it is a nested expression with three function applications.  If you
> want to evaluate it in left-to-right order, you have to do the
> following:
>[...]

> If you want to optimize this to get something as efficient as O'Caml
> currently is, you have to know that f doesn't do any side-effect
> before receiving all its arguments, which is generally impossible.
> With right-to-left, the compiler doesn't have to know anything about
> f.

This is also addressable with my suggestion (which I posted last
night, but hasn't made it to the mailing list yet) of annotating
results of functions that cause a side-effect.  So, in your example,
instead of the existing:
	# let x = ref 0;;
	val x : int ref = {contents=0}
	# let f w y = incr x;let x' = !x in function z -> w+x'+y+z;;
	val f : int -> int -> int -> int = <fun>
you would get instead:
	val f : int -> int -> (int -> int effect) effect = <fun>
now when you apply it:
	f e1 e2 e3
you get an error if e3 is also an effect value, because the order of
evaluation between the evaluation of (f e1 e2) and (e3) might cause a
problem.  So you would be forced to rewrite it as:
	let f' = f e1 e2 in f' e3
or
	let e3' = e3 in f e1 e2 e3'
whichever reflected the order of evaluation that you want.  Note that
you would not get an error if e2 was an effect value because it must
be evaluated (because of ml's strict semantics) before f is applied to
it, and it doesn't matter whether e2 is evaluated before or after (f
e1) is.  Similarly, it does not matter if e1 is an effect value
because it has to be evaluated before f can be applied to it.  (Note
that if f was an expression that itself was an effect, this wouldn't
be true.)  If e1 and e2 were *both* effect values, then there would be
a conflict between them and you would get a compilation error.

(Note that in my other posting I suggested a refinement of this that
would get finer granularity on the conflicts, but the principle is the
same.)  This is somewhat related to monads, but with ocaml's strict
semantics it need not be as intrusive as monads.

../Dave
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr