FW: RE [Haskell-cafe] Monad Description For Imperative Programmer

[Dan Weston]

Here's my rant about the way monads are explained in Haskell tutorials 
(which are much too polluted with nuclear waste to be safely approached):

It is a big mistake to start with the IO monad. It pollutes and 
misdirects the understanding of what a monad is. The dreaded "nuclear 
waste" metaphor is actually a red herring, having nothing do do with a 
monad at all, merely the artifact of the absence of an exit function in 
the IO monad (which actually does exist and is called unsafePerformIO, 
but that is a secret. Shhh...), combined with Haskell's refusal to work 
for free.

Monads are required to have an extrance (reification/constructor 
function) called return. They are *not* required to have an exit 
(reflection/deconstructor function).

They *do* combine (bind) together like links in a chain, which is not a 
list but an equivalence class of trees, where the only thing that 
matters is the order of the leaves, so unlike a list you don't have to 
start at the tail and assemble one-by-one. [Actually, the compiler picks 
just one of these trees (the singly-linked list) but expects that all 
trees would evaluate the same.]

They *do* bind only with flavors of themselves (State a cannot bind to 
IO b, though a monad transformer can merge the two). The output type of 
one monad instance must match the input type of another monad 
reification function (e.g. return) that it wants to bind to.

In compensation for this tribalism, those snobby monads that want to 
clique off are out of luck: a monad cannot restrict what possible types 
can be used to construct a monad instance. That would be discrimination, 
and you must agree to accept all comers.

Simple, no? Apparently not...

Other things have nothing to do with monads per se gunk up the 
descriptions about monads:

One red herring (the nuclear waste metaphor) refers to the fact since 
monads may or may not have an escape-clause (called variously runXXX, 
evalXXX, unsafePerformXXX), and IO in particular does not. The presence 
or absence of this has *nothing* to do with monads (only with IO), 
participates in no monadic laws, and shouldn't even be in the chapter on 
Monads. Whether nuclear waste seeps in (as in a State monad) or stays 
out (IO monad) has nothing to do with their monadic property and is a 
special property of those particular classes.

Another even redder herring is the dreaded sequencing aspect. Monads do 
sequence *denotationally*, the way any nested closures sequence, which 
is exactly *backwards* from the naive understanding of sequencing: 
symbols defined to the left are in the *inner* scope, those to the right 
are in the *outer* scope. Perversely, when the symbols are evaluated, 
the rightmost monad is evaluated first. The leftmost monad in the 
program, the IO () passed in by main, is the *last* thing to be 
evaluated, not the first. The outermost monad (rightmost bound function) 
is in the driver seat, and is absolutely free to ignore the monad to its 
left (which in turn encloses monads to its left)! This includes of 
course the main input IO () monad.  Don't believe me?

Prelude> const 3 (return "Nuclear waste leaking..." >>= print) + 5
8

Phew, no nuclear waste leaked after all. What a relief!

This sequencing then has nothing to do with *operational* sequencing. 
When the symbols are evaluated is the basic call-by-need data-dependent 
stuff of most Haskell symbols and again, has nothing to do with monads.

I learned about the IO monad first and I regret it bitterly. It cost me 
a years' worth of misunderstanding. I misapprehended that a monad had 
something to do with nuclear waste and never escaping the 
single-threadedness. I hope the new O'Reilly book doesn't make that 
mistake. Teach IO right away, but just don't call it a monad. IO is the 
exception, not the rule, in the menagerie of Haskell monads.

How does all this map to C++? A monad is a a class, with no useful 
interface for the end user, that looks roughly (i.e. I haven't tested 
it) like:

template <class M, class T>
class Monad
{
public:

   virtual ~Monad() {}

   // return
   Monad(T t) : t_(t) {}

   // bind operator (>>=), where
   // F :: Monad<M,T> -> (T -> Monad<M,U>) -> Monad<M,U>
   virtual template <class U> Monad<M,U>
     operator>>(typename U::F f) = 0;

private:
   T t_;
};

C++ programmers will immediately see past the syntactic kruft to notice that
1) the constructor arg is not a value but an unevaluated function 
object, that starts out unevaluated.
2) The result of m >> f is a monad object, totally unevaluated.
3) There is no member function to do anything with the monad at all! As 
is, it is useless.

Derivers of this class will naturally want to add such functionality:

template <class M, class T>
class MyMonad : public Monad<M,T>
{
   // The parent class needs to know what type of monad
   // this can bind to
   typedef someUnaryFunctionObjectTypeReturningB F;

   // There is no input, just an output!
   // The input is via the constructor arg of the innermost monad
   B operator()() { ... start the ball rolling ... }
};

Non-C++ programmers will be stunned that the above garbage can be 
understood by anyone, compared to the simplicity of type classes in 
Haskell. When all you have is a hammer...

The moral of the story is that monads are less than meets the eye. You 
can create them and concatenate them, but may not be able to do anything 
with them (some monads do let you, some don't), though the runtime 
system agrees to evaluate one special monad exactly once.

What the rightmost monad does with its internals (including all 
inner/left monads bound to it) has nothing to do with monads whatever, 
except for the minimal requirement that they agree to be bound only to 
other monads like themselves, and that as a group they all agree to not 
form a clique (i.e. they are associative).

What could be simpler that that? No please, no more nuclear waste! :)

Dan

peterv wrote:
> Kaveh> "A monad is like a loop that can run a new function against its variable in each iteration." 
> 
> I’m an imperative programmer learning Haskell, so I’m a newbie, but I’ll give it a try ☺ Making mistakes is the best way to learn it ;)
> 
> There are lots of different kinds of monads, but let’s stick to the IO monad first, which you seem to refer to.
> 
> No *an IO monad is not a loop at all*. Instead, from an imperative programmer’s point of view, the following might be better:
> 
> “an IO monad is a delayed action that will be executed as soon as that action is needed for further evaluation of the program.”
> 
> The simple program
> 
> main = getLine >>= putStrLn 
> 
> can be visually represented as (see attachment)
> 
> The “world” (=a representation of your computer’s hardware) is passed to the main function, which passes it to all actions that it encounters during its lazy evaluation, causing the executing of the actions as an effect. 
> 
> The red wire through which the “world flows” is a “single thread”, it cannot be split (because the physical world cannot be copied!!!), so no unwanted side effects can ever occur, making IO safe in Haskell. 
> 
> When you write your IO program, this world object is never available (the IO type is a special internal type), so the red wire is erased from the diagram, and the getLine and putStrLn boxes become “delayed actions”. 
> 
> Imperative programmers like myself might initially be confused when they see Haskell’s do notation, because it looks like the actions are strict statements as in C/C++/Pascal/Java/C#/etc, but they are not.
> 
> For example, try the following program:
> 
> main = do last [
>            putStrLn "NOT executed although it is first in the list, as it is not used by the main function!",
>            putStrLn "This action IS executed because it is evaluated by the main function." ]
> 
> This is of course all due to Haskell’s laziness which only evaluates just those expressions that it needs to evaluate the main function.
> 
> One thing to note in the diagram above is that the getLine box has TWO outputs, the String and the World. But functions can only have a single output, but this can be tuple. Hence the passing of the world from one box to the other is a bit more complicated. It is this pattern of extracting both values from the output and passing them to the next function and other related combinations that form the generic monad class, which can be used for many more things than IO.
> 
> See http://haskell.org/haskellwiki/IO_inside for a much deeper and more correct explanation ☺
> 
> And for the pros here, did this newbie make any sense? Probably not ;-) 
> 
> Oh no, yet another monad explanation!!! Now the universe will most certainly collapse… 
> 
> 
> No virus found in this outgoing message.
> Checked by AVG Free Edition. 
> Version: 7.5.476 / Virus Database: 269.11.0/929 - Release Date: 31/07/2007 17:26
>  
>   
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe