Version française
Home     About     Download     Resources     Contact us    

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

Browse thread
Haskell vs OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: blue storm <bluestorm.dylc@g...>
Subject: Re: [Caml-list] Haskell vs OCaml
> One is that Haskell forces your program into two parts.  Parts that contain
> side-effects (in monads) and the part that is pure.

You can actually do quite a bit more, using different monads to
compartementalize different aspects of your code. You will, by the
way, have noticed that Haskellers tend to put everything in the IO
monad (when a separate monad would make more sense) because mixing
monads is difficult.

> This is great because
> the compiler can now do some optimizations not available when you don't know
> if your code is pure.

I suppose you could get the same benefits with a "purity inference"
compiler pass, the same way haskell compilers a "strictness

> it makes side-effect creep very obvious (when you realize "oops, that needs
> to be in a monad too... and that... and that ... crap").

unsafePerformIO to the rescue !

I generally agree with the interest of pure programming in some part
of the language. It is, however, not all as rosy as you say (i've seen
people argue that the "side-effect creep" related to monads cause
composability problems) because they are hard issue (monads mixing for
example) wich have not been quite resolved yet. Haskell is interesting
because of that experimental taste, but i totally agree it "sometimes
gets in your way".

> A similar argument follows for lazy (non-strict) evaluation as well.  Allows
> some really cool stuff (eg. infinite lists) and optimizations (eg.
> deforestation).

Explicit lazy evaluation (as in OCaml) can give you the same cool
stuff, with a saner standard (strict evaluation) and, in my opinion,
increased comprehensibility (by explicitely highlighting the part that
rely on lazy evaluation). Both library and syntaxic support of lazy
values in OCaml could be better that they are now, but they is work
going on (we even have *several* lazy lists librairies these day).

> That's true, but I think Haskell's point of view is to stop that completely.
> They want to remove optimization of code and put it into the hands of the
> compiler.  The ideal is to say to the programmer: "don't worry about
> performance and optimization, just write correct code.  The compiler will
> figure out the rest".

I strongly disagree on that point. You just can't rely on anything
that optimizes "as much as possible" when you don't know precisely
what it does. The idea to "not worry about performance" is, in my
opinion, wrong because you'll always have specific cases wich are not
correctly optimized (see for example the posts on the performance of
high-level automatic differentiation stuff that went on the Haskell
planet a month ago or so). The usual programmer should not need to
know about subtle and implementation-specific stuff (whereas the
requirement of understanding tail-recursion is commonly accepted among
OCaml programmers), but trying to optimize every naive code into
something efficient is a dangerous dream.