Hi all, I've been following this discussion with some interest. Last time I looked, hugs, ghc and nhc98 all implemented I/O differently. No doubt there are even more alternatives in other Haskell implementations (real or imaginary). In itself this is probably not too surprising. They are, afterall, different systems with different goals etc. However, I have often wondered what it is that constitutes a correct implementation of the I/O system in Haskell. I might be wrong, but I don't think the Haskell Report helps much in this regard. The only source of semantics for Haskell's I/O that I know of is "Tackling the Awkward Squad" by Simon Peyton Jones. If there are others I'd love to have them pointed out. However, this paper deals with many extensions that are not in Haskell 98. I'm not sure if there is enough in it to decide if a given implementation is correct (I use the word "correct" loosely). I would really love to see a discussion of the design space for I/O. Including what the current compilers use, what other options there might be, and even what other languages use (like Clean's and Mercury's uniqueness systems). If I were to build a Haskell compiler tomorrow this is one thing I would like to know - what do I have to do to ensure that my implementation of I/O is correct and what design options do I have? No doubt the I/O systems of current compilers have grown with those systems, but from the perspective of someone who is outside of the implementations it would be interesting to know why things are done the way they are, and what other options were considered, rejected, etc. For example, the state-of-the-world threading approach might be chosen because it is economical with respect to implementation cost in an existing compiler (such as GHC). But if we were to write a compiler from scratch would/should we follow the same route? Also, the "Keep the monad right through" method that Simon mentions in the "awkward squad" paper is interesting, but I wonder if that is too hard to implement in Haskell due to extensive overloading of the monad operators. I'll stop rambling now. Cheers, Bernie.