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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
