Thanks Oleg, this is very interesting! I thought one big selling argument
of monads was also that the type of the functions shows which effect it
performs. As I understand it, it is not the case for effects, at least not
in existing implementations like multicore ocaml. Isn't this considered a
concern, just like exception-raising functions are increasingly discouraged
at the benefit of explicitly specifying partial functions with a result
type? Also, would you know a reference that shows that effects compose
indeed a lot more easily than monads? In my (very limited) experience,
composing two monads sometimes require a little thinking and not so trivial
implementation to be defined.

2017-10-27 15:58 GMT+02:00 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.
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>