Re: [Caml-list] What if exn was not an open type?

[Oleg <oleg@okmij.org>]

It is interesting that we have this discussion about, even advocacy
for, monads at the time effects are coming to the front stage. The
language Eff (http://eff-lang.org), which is essentially OCaml, states
right upfront its advantages over monads. (Monads do not compose.)
Daan Leijen talk past month about the web server implemented in Koka
stressed the absence of monads. In Koka, if we need an effectful
operation, we just do it. As the Multicore OCaml project has shown,
effects can be very efficiently implemented. 

I fully agree with Ivan Gotovchits that recommends Rich Jones' code
rely on exceptions rather than monads. Where I disagree is the
contention that ``When you need to write system code or any code that
deals with effects, monads become inevitable sooner or later unless
you're willing to use the escape hatch of mutability.'' Monads are not
inevitable!

First of all, not all effects can be represented as monads (which was
pointed long time ago by Wadler himself). My talk at the ML workshop
last month
        http://okmij.org/ftp/tagless-final/nondet-effect.html
described several other effects that aren't monadic and that
commitment to monads precludes several useful implementations (e.g.,
code generation, which cannot be thought in monadic terms).  Hence,
there is real harm in trying to squeeze everything into a
monad. Incidentally, alternative ideas of effects as interactions go
back to 1970s.

Richard W.M. Jones wrote:
> Having said all that I was writing a little ML language last
> year and I tried to implement a return statement, but it was very
> awkward to work out how to map that to my lambda calculus, so
> I understand how return statements are rather difficult to implement
> in practice.

Perhaps this gives a hint that lambda-calculus isn't the best model of
computation -- as the Founding Father has recognized very early
on. There is a reason he spent his life after ML working on process
calculi. Indeed, it takes lots of hops to implement a simple return
statement -- not to speak about real IO -- whereas it a process
calculus, we just say !a. Done. Sending the result to another process
(or to the context) is a built-in operation. There are no
continuations to pass around or capture, no monads (which become
totally unnecessary), no binding. Erlang has shown very well that this
way of programming is realistic, and rather effective.

lambda-calculus has its uses: it works spectacularly well for what it
has been designed for: expressing definitions (and logical
derivations). However, just because it is possible to express
arithmetic in lambda-calculus does not mean that we should be stuck
with Church-numerals. There are better ways to handle numbers -- and
there are better ways to handle communication and control -- outside
lambda-calculus.