Fwd: Re: Yet Another Monad Tutorial

Iavor Diatchki diatchki@cse.ogi.edu
Wed, 13 Aug 2003 16:18:09 +0000


sorry for asking so many questions :-)

blaat blaat wrote:
> ...
> 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.
what do you mean by "you can't get anything out of it"?, i.e.  what can 
you get out of (3::Int)?
what do you mean by "introspection", from the text bellow it would seem 
that you mean some sort of reflection, where a program can examine 
itself?  such programs tend to be hard to understand.

> 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?
there are many other functions that cannot be written in haskell (and 
often there are good reasons for not allowing them). again what you 
point out is not specific to monads or IO in any way.  consider a 
function: "unparse :: (Int -> Int) -> String"  that given a function 
will produce its definition.  you cannot write such a function in haskell.

  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.
being able to write such a function has nothing to do with IO being a 
monad or not. to be a monad you need a suitable definitions for 'return' 
and '>>='.  adding _more_ functions, does not cange anything.

> 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).
you are quite right that there are alternatives to monadic IO.  in fact 
haskell used to use stream-based IO.  you are also right in that IO 
being a monad is not the central issue contibuting to "purity".  what 
ensures "purity" is the fact that the type system keeps track of IO 
operations (and similarly stateful computations in the case of ST). this 
is in contrast with ML (or C) for example, where an expression of type 
'int' can print to the screen, so the type system is unaware of 


| Iavor S. Diatchki, Ph.D. student               |
| Department of Computer Science and Engineering |
| School of OGI at OHSU                          |
| http://www.cse.ogi.edu/~diatchki               |