> 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!
No, I don't believe you.
It's true that the right monad instance can ignore its left sibling
(same monad of course, just a different instance) to allow backtracking
(the Const monad being a trivial example of this), but IO is not such a
monad.
Your example just shows that monad instance expressions (like any
Haskell expression) are evaluated lazily in Haskell.
I am relieved though, that no nuclear waste was leaked by your example.
Dan Weston wrote:
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
