Yet Another Monad Tutorial
Wed, 13 Aug 2003 09:44:36 +0200
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 ;-).
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*