Yet Another Monad Tutorial

[Derek Elkins]

On Wed, 13 Aug 2003 09:44:36 +0200 
"blaat blaat" <l4t3r@hotmail.com> wrote:

> 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.