[Haskell-cafe] Martin Odersky on "What's wrong with Monads"

Chris Dornan chris at chrisdornan.com
Mon Jun 25 08:26:32 CEST 2012

On 24 June 2012 18:46, Alexander Solla <alex.solla at gmail.com> wrote:

> I sort of see where you're coming from.  But I'm having a hard time seeing
> how this "complaint" would work with respect to Maybe and the other pure
> monads.  In other words, I suspect the problem you're describing is
> particular to IO and IO-like monads.

Yes this problem is specific to IO-based functions. If you didn't know
anything about monads yet would have written a Maybe/Either function then
the types are identical to the monadic formulation, and the monadic
framework in this case is just helping you to structure everything. Unless
this structucture is obscuring or confusing matters (and I don't see it)
its difficult to imagine any objection here.

> I don't know SML.  How is our list "monadic" and theirs not?  In
> particular, how is Haskell "forcing" the reification while SML does not?

In SML you can put side-effecting computaions in 'pure' functions --
functions whose type doesn't reveal that there are side effects. In Haskell
terms, every function is actually in the IO monad -- or every function is
given carte blanche to use unsafePerformIO depending upon how you look at
it. In semantic terms it is really a case of the former; from a programming
perspecive it is more like the latter; Standard ML is strict and I am
pretty sure this is only practical in a strict language. It is (IMHO)
deeply horrible, and possibly justifiable before monadic I/O was invented
(but not for me).

I am not advocating doing this (at all) but using it to illustrate a point.
In standard ML you can start doing effect-based things inside a function
without having to alter its type and they type of everything that uses it,
and so on.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120625/8200f15a/attachment.htm>

More information about the Haskell-Cafe mailing list