On Tue, 2006-01-24 at 09:17 +0000, Simon Peyton-Jones wrote: > | Is there any reason why IO should not be defined as: > | > type IO a = ST RealWorld a > | in implementations that support ST? > | > | This way IORef/STRef and IOArray/STArray can be merged. I know under > the > | hood they already share code, but this way they can also share an > interface. > > Indeed, this was the way we had it originally in GHC. It does seem like > a good idea. We changed it for reasons that I know that we have > forgotten, alas, because we tried to recall about a year ago. It's > always possible that the original reasons for the change no longer > apply. > > Perhaps someone can try it out?
Is the reason for not having this type synonym maybe "bad type error messages"? In my program, I've got a type synonym just like that: type ExecM a = StateT FixpointState (ReaderT ProgReaderState IO) a When I erroneously give the simple function warn :: Context -> W.Warning -> ExecM () warn ctxt warn = do .... an extra argument in the type signature warn :: Context -> W.Warning -> Int -> ExecM () I get: Couldn't match `(->) Int' against `StateT FixpointState (ReaderT ProgReaderState IO)' Expected type: Int -> t Inferred type: ExecM () Even if you've defined the type synonym yourself, it takes a while to realise that the type synonym and the ExecM () are the same, in particular since the type variable t is omitted in the first part. There are many other places in the libraries which could do with a generalisation of types, but where similarly difficult type error messages will arise. One function that particularly annoyed me is in Control.Exception handle :: (Exception -> IO a) -> IO a -> IO a should be handle :: MonadIO m => (Exception -> m a) -> m a -> m a to be usable with my ExecM monad. liftIO doesn't really help here. If it weren't for the type error messages, I would suggest to generalise all function using IO a to MonadIO m => m a. Axel. _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell