This site is updated infrequently. For up-to-date information, please visit the new OCaml website at ocaml.org.

Strange evaluation order
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
 Date: 2002-05-19 (11:59) From: Michel Quercia Subject: Re: "ocaml_beginners"::[] Strange evaluation order
```Le Sun, 19 May 2002 21:50:04 +0200
Nicolas Barbulesco <nbarbulesco@y...> écrivit :

> > You can force a left-to-right evaluation order by stating it
> > explicitely :
> >
> > # let f = firstOfTheTwo (double 5) in f(double 6) ;;
> > double 5
> > double 6
> > - : int = 10
>
> How Caml can do something different ? I don't understand why specifying
> this changes.

let x = something in something-else is granted to evaluate "something"
before "something-else" because "something else" might depend on the
identifier bound (x above). And even if "something-else" does not depend
on this identifier, this granted evaluation order ensures that side
effects are done in a known order.

I thought that (because the function is curryfied) when I
> call firstOfTheTwo a b Caml did exactly that : applying firstOfTheTwo to
> a, and applying the result to b, which corresponds to what you wrote
> with the let f = firstOfTheTwo a in f b syntax. And which corresponds
> too with #trace : an intermediary function (firstOfTheTwo*) appears, and
> is applied to b.

I write f for firstOfTheTwo below:

"f exp-1 exp-2" means "(f exp-1) exp-2" that is to say :

My dear Ocaml machine, please evaluate (f exp-1) and (exp-2) in any order
that you want, then apply the first result (f exp-1) with the second one
(exp-2) and send me back the final result. Thanks.

If you trace the function f, then you'll see that (f exp-1) is evaluated
before (res-1 res-2), but you don't see in which order res-1 and res-2 are
evaluated.

On the other hand, "let res-1 = f exp-1 in let res-2 = exp-2 in res-1
res-2" means :

evaluate ... exactly in the order specified ...

... lazyness ...
> OK, thanx. This is even a little more lazy that what I told, because b
> is sometimes needed (not never) and evaluated only when needed. But,
> with this on-demand evaluation, is there the side effect that if b is
> needed twice it will be evaluated twice ?

No. The first Lazy.force will trigger the computation of b and this result
will be cached for subsequent calls to Lazy.force.

> If there is not this
> side-effect, we can call this the ideal lazy evaluation, or ?

We can.

> By the
> way, is there any advantages of eager evaluation compared to ideal lazy
> evaluation ?

Compactness and speed. Recording the expression to be evaluated on demand
and checking if it is in the cache or not on each access costs some memory
(begign) and some time (worse). Lazy values are mainly interresting (in my
opinion) when dealing with infinite data streams that you don't want to
expand completely before processing. Otherwise ordinary values are more
efficient.

Regards,
--
Michel Quercia
23 rue de Montchapet, 21000 Dijon
http://michel.quercia.free.fr (maths)
http://pauillac.inria.fr/~quercia (informatique)
mailto:michel.quercia@p...

```