On Mon, 2007-01-15 at 00:55 +0000, Jon Harrop wrote:
> On Sunday 14 January 2007 23:38, Gabriel Kerneis wrote:
> > Le Sun, 14 Jan 2007 20:49:57 +0000, Jon Harrop <jon@ffconsultancy.com>
> > a écrit :
> > > Playing with Haskell and F# has opened my eyes a bit. F#'s operator
> > > overloading and active patterns will make my code much nicer. Being
> > > lazier can simplify things until you have to optimise, in which case
> > > it suddenly becomes really complicated and error prone.
> >
> > What do you mean exactly in this last sentence ? I agree OCaml should
> > evolve but what kind of "laziness" are you referring to ?
> 
> Lazy (as opposed to eager) computation. OCaml is very eager. Using laziness 
> more can speed things up in some simple cases, e.g. nested maps and folds.

This is not clear. Laziness can be very fast if well optimised,
but optimisation is hard in general. The trivial case of nested maps 
and folds can be optimised by hand in Ocaml.

It also isn't really true Ocaml is 'eager' in 'general'.
Almost all constructions in all languages are in fact lazy:
indeed procedural/imperative programming is ultimately lazy.
A simple example: Ocaml match is lazy:

  match x with | true -> t | false -> f

evaluates t or f lazily .. in general this is obviously
necessary since any pattern variables (not exhibited in 
this case) are not known until the match is done.

At best you can say function application in Ocaml is eager,
and even that isn't true: wherever you use a reference,
you're passing a pointer, and that's lazy evaluation,
until you 'eagerify' it by dereferencing the pointer.

Similarly when you pass a mutable data structure as an argument,
evaluation is actually lazy .. operations on it are done
*inside* the function body.

So actually, in an imperative language like Ocaml, there is no
real need for lazy evaluation of function arguments .. there
is already plenty of control over evaluation time. The main
downside is that the programmer needs to exert this control
manually .. and that is also the main upside, compared to
say Haskell, where you really don't know how good a job
the optimiser is doing precisely because of the lazy semantics.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net