On Wed, 13 Aug 2003 09:44:36 +0200
"blaat blaat"
Hmmm, I personally always thought of the IO monad as being a synonym for "Program"
So. What is a "Program"? [...]
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?
Not for the reasons you describe below.
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?
That would be confusing to use or restrictive (unless done exceedingly well perhaps), it would be awkward to define, and it would pretty much require arbitrary design decisions (what should be included in this language? what are it's semantics? etc).
Why not have (some limited) introspection on programs which we build?
It would be round-about in both implementation and use to do this. Nevertheless, you can easily view the IO monad as an imperative language -embedded- in Haskell. Even when writing mostly imperative code Haskell gives you much more flexibility and protection than many imperative languages, especially the more popular ones. [...]
Are we missing out on usefull stuff?
No, but if we were, it'd be trivial to test/get it with an appropriate top-level runTheProgram IO computation definable in Haskell today.