Yet Another Monad Tutorial

[blaat blaat]

Hmmm, I personally always thought of the IO monad as being a synonym for 
"Program" (or, for functions wich return an IO a, "a subroutine with 
side-effects which returns a value of type a").

We can build mini programs (like putStr), and compose them in a sequential 
manner (including something alike assignment).

I personally use the following analogy. Someone, somewhere, sometime must 
have thought, "Great, if I cannot do imperative programming directly, I can 
damned well create imperative programs and have _them_ evaluated, grumbl!" 
And with that thought, he solved numerous problems ;-)

Can we really make cheese out of it? (Dutch saying)

For what is the interpretation of an object of type IO a? Well, it is a bit 
of a hack atop of Haskell, isn't it? If we return a complex type with an IO 
a object in it, the object cannot be evaluated, but if we return a IO object 
solely (program), the program get evaluated (passed to the (Haskell)-OS).

However, given that observation, the fact that IO is a monad I find to be a 
_rather arbitrary design decision_; why not define a small term language 
which may be passed to the OS? Why not have (some limited) introspection on 
programs which we build? Purity will never be broken since the only way to 
get a "program" evaluated is to pass it to the Haskell-OS. Are we missing 
out on usefull stuff?

Hehe... God, we might as well just generate impure graph rewrite rules,.... 
or plain C for that matter ;-).

Cheers, l4t3r

ps: Mind you, nothing wrong with that IO monad. It works, why break it. ;-)

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail