On Wed, 2008-08-27 at 23:00 +0100, Lennart Augustsson wrote:
IMO, there's no justification for having IORefs etc in the IO monad. They should be in a separate monad. There could then be an operation to lift that monad to the IO monad, if you so wish. But wait, we already have that, it's the ST monad! (So there is no justification.)
Right. We'd have ST (which has the advantage that, if you don't have any free variables of STRef type, your code can be used in a pure context), together with a monad homomorphism stToProgram :: ST RealWorld alpha -> Program alpha We'd also have IO (stripped of IORef, Random, Unique, and other such irrelevant ugliness), together with a monad homomorphism ioToProgram :: IO alpha -> Program alpha Then, the top-level type rule would be Main.main :: Program () We'd flame people for using the Program monad outside of the Main module or monad homomorphisms like ioToProgram or stToProgram. Then, using the functional programming language research of the last 20 years instead of ignoring it for historical reasons, we'd get a free monad homomorphism ioAndStToProgram :: Coproduct IO (ST RealWorld) alpha -> Program alpha which would let you use both in the same program. It doesn't dispense with the need for top-level Program (yet), but it's a step in the right direction. jcc