Fwd: Re: Yet Another Monad Tutorial

[blaat blaat]

>From: Derek Elkins <ddarius@hotpop.com>
>"blaat blaat" <l4t3r@hotmail.com> wrote:

[...]

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

Trivial to test I fully agree with; however, to the missing out on usefull 
stuff I am not convinced. Please allow me to continue my trolling.

To use the IO monad for impure calculations is, of course, a design 
decision. It is arbitrary to the point that I have the freedom not to agree 
with it; but hey, even I know the thing works ;-).

The key point to my email was that doing impure IO possibly has little to do 
with a monadic style of programming but with the fact that we can 
functionally construct a description of an impure program which is evaluated 
_only_ when delivered as a sole result of a Haskell computation. I find that 
somewhat odd; but not to the point I cannot live with it ;-)

About the indirectness issue. The benefit of choosing a monad is clear - the 
evaluation/rewrite of an action corresponds directly with an impure 
subroutine call. Moreover, the action can be discarded and, as you pointed 
out, the description of these impure subroutine calls are trivially embedded 
directly into Haskell - giving typesafety as a reward. It is both effective 
and efficient.

Great.... Hail to the monad!

Hmmm, uhm, but let's think further...

What did we lose? Well, introspection comes to mind. A monad is strange in 
the sense that, actually, there does not seem to be any reason to compute 
its value since we cannot possibly get anything out of it. In case of IO, 
only the haskell interpreter can. And, introspection is a nice thing to 
have, especially for compiler writers. Although I think the benefits in 
Haskell would be limited, an application might be that I could write my own 
promotion functions on my own programs.

Think of the following though experiment. What if I would have a function 
"unparse:IO a->String" which gives the textual representation of the 
specification of the object of type IO a? Clearly, IO is not a monad 
anymore. Moreover, I don't think it would break the purity of Haskell. And 
surely, in case of the IO monad, we can think of better manners to break a 
program down.

Hmm, I am rambling. The point is, I think there is no reason to discard all 
alternatives to monads; I believe that central in the IO-issue is not the 
fact that we are using monads for IO - but that we can purely create impure 
programs which do the IO for us ;-), and that those do not have to be of the 
monadic kind (with all respect to the baffling ingenuity of the invention).

Cheers,
  l4t3r

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963