Re: [Caml-list] Evaluation Order

[Damien Doligez <Damien.Doligez@inria.fr>]

>From: Brian Rogoff <bpr@best.com>

>No, this is a language problem. Lots of people who teach OCaml have mentioned 
>that this is an issue. If the clash with expectation is so great then that
>You should always be careful about sequencing in imperative style programming, 
>but IMO this is one of those few things that SML does right that OCaml does 
>not. As you say, there is a very strong expectation that events occur in
>the order that we read them. The original arguments about optimizations
>and parallelism don't seem to have borne fruit, so it would be good to fix
>this.

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:

1. evaluate f
2. evaluate e1
3. evaluate f (e1)   (call the result f1)
4. evaluate e2
5. evaluate f1 (e2)  (call the result f2)
6. evaluate e3
7. evaluate f2 (e3)

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.

For years I thought that the only solution to this problem would be to
move away from currying by changing the preferred programming style to
passing tuples or records (as SML does).  But people at INRIA are
overly fond of currying for some reason.

Now I think there's another solution.  Let's just have different
semantics for  (f e1 e2 e3)  and  ((f e1) e2 e3) :

f e1 e2 e3 should evaluate f, then e1, then e2, then e3, then do a
ternary application.

(f e1) e2 e3 should evaluate f, then e1, then do a unary application,
then evaluate e2, then e3, then do a binary application.


I think this solution should work, and retain all the efficiency of
O'Caml.  The question is, how much does it interfere with labels and
optional arguments ?

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