Yet Another Monad Tutorial
Bernard James POPE
Fri, 15 Aug 2003 18:56:03 +1000 (EST)
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
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.