

OCaml for Haskellers - mahipal
http://blog.ezyang.com/2010/10/ocaml-for-haskellers/

======
catechu
In addition to the mutable records mentioned in the post, arrays and
references are also mutable in OCaml. Aside from objects, I consider this
impurity to be the biggest difference in practice. Mutability allows simple
OCaml solutions to problems that would otherwise demand monadic gymnastics in
Haskell.

FWIW, I've also never been able to design a large project in Haskell (a la
darcs), whereas I could write fairly large projects in OCaml without much
awkwardness. I suspect the ability to "cheat" with mutability outweighs in
practical terms the theoretical elegance and enjoyment of programming in
Haskell.

~~~
jrockway
"Cheating mutability" is trivial in Haskell. You import Data.IORef or
Data.STRef and do your thing. (unsafePerformIO is just runST for "real world"
actions.)

You'll find, though, that it's very easy to make a sequence of mutations
become one pure operation, and the ST machinery lets you keep that sequence
encapsulated. This is how building a vector works. In a new state thread, you
allocate the vector. You run a pure function to generate the nth element. You
bit-bang that into memory. When you're at the end of the vector, you freeze
the vector into an immutable vector and return it. The final signature is
"Length -> (Index -> Value) -> Vector of Values". Totally pure to the outside
world, mutable internally. And the type system keeps the mutation part safe!

So while the first approach you try with Haskell should be actual pure code,
you still have the tools you need to be as impure as you need to be. And you
can still keep your program type safe, if you want.

~~~
ezyang
It's most of the way there, but not quite. For example, one frequently wants
to do a hybrid approach to mutability where construction of the data structure
is destructive, but then further manipulation is persistent. ST-backed arrays
will get you part of the way there, but there's no easy way to efficiently
unsafely freeze (the unsafe coercion from mutable to immutable) recursive
mutable structures into persistent structures. You have to very carefully make
sure the internal representations match up, and it's tricky enough that it's
not done very often. I guess my real point is there is a cognitive cost for
respecting the fine distinctions that Haskell makes you think about, which
discourages certain styles of programming, but is good for the mind. :-)

~~~
jrockway
IORef is exactly equivalent to any other mutable variable.

If you want to write C in Haskell:

    
    
        import Foreign
        foo = mallocBytes 42 $ \p -> do
            whatever <- peek p
            poke p $ f whatever
            ...

