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