Re: [Caml-list] Re: variance, subtyping and monads... oh, my!

[Frank Atanassow <franka@cs.uu.nl>]

Francois Pottier wrote (on 19-11-01 09:11 +0100):
> Isn't that a bit harsh? Monads offer abstraction with respect to the way
> certain side effects are performed. Because of ocaml's natural support for
> many side effects (references, exceptions, I/O, ...), monads are seldom
> needed in ocaml.

What may make monads less useful in Ocaml than in Haskell is not the native
support for side effects but rather the call-by-value evaluation. This is
illustrated by the fact that all the Haskell implementations which support the
IO monad also have native side effects, because that is the most efficient way
to implement references. (An alternative is to thread the state through
the computation explicitly, and do functional updates.)

Another way to say this is that Ocaml already supports a monad, namely the one
for CBV computations. It throws everything ("references, exceptions, I/O,
..") into this one monad, much like Haskell98 throws everything into the IO
monad.

Where Haskell has an advantage is that you can write new monads, and combine
them at will. "Monad transformers and Modular Interpreters" [1] is a good
example of the power this gives you.

Personally, I think Ocaml programs could benefit from being written in a
monadic style; I know I've been bitten by side effects on more than one
occasion. But I'm not sure if Ocaml's type system is up to the task, and I'm
also concerned that it won't optimize away all the consequent CPS-style code
the way GHC does.

[1] Sheng Liang, Paul Hudak, and Mark P. Jones. Monad Transformers and Modular
    Interpreters. In Conference Record of POPL'95: 22nd ACM SIGPLAN-SIGACT
    Symposium on Principles of Programming Languages, San Francisco, CA,
    January 1995. (http://www.cse.ogi.edu/~mpj/pubs/modinterp.html)

-- 
Frank Atanassow, Information & Computing Sciences, Utrecht University
Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands
Tel +31 (030) 253-3261 Fax +31 (030) 251-379
-------------------
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