# Threading monads

**Jan-Willem Maessen
**
jmaessen@MIT.EDU

*Fri, 11 Apr 2003 09:48:07 -0400*

Jon Cast <jcast@ou.edu> replies to me:
>* Jan-Willem Maessen <jmaessen@MIT.EDU> wrote:
*>*
*>* > Actually, though the operations of most monads constrain evaluation
*>* > order, an interesting property of the identity monad is that it should
*>* > not do so. This observation has led me to think long and hard about
*>* > the distinction between monadic and non-monadic computations in
*>* > Haskell (admittedly to no real conclusion).
*>*
*>* Why would you do this? I don't see what conclusion you could come to
*>* that would involving discarding the ID monad, so you'd still need to
*>* distinguish between different monads.
*
Indeed. But how about moving in the opposite direction? What if we
viewed the purely functional subset of Haskell as computations in an
arbitrary monad (by default the identity monad)? Then, for example,
it would be sufficient to write the purely functional definition of
"unfold" and expect a reasonable monadic program.
Then the problem changes: because all computation is monadic, how do
we express new monads? And how do we express the transition from one
monad to another? Without some sort of mediation, all our
computations might occur in "IO", which is not very satisfying.
And of course in the monadic world a lot of things suddenly become very
explicit (e.g. the binding order of function arguments) which are
deliberately unimportant in the purely functional world.
-Jan-Willem Maessen
jmaessen@alum.mit.edu