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

1 Aug 2007

      ...
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 Monad
{
public:
virtual ~Monad() {}
// return
  Monad(T t) : t_(t) {}
// bind operator (>>=), where
  // F :: Monad -> (T -> Monad) -> Monad
  virtual template <class U> Monad
    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 MyMonad : public Monad
{
  // 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