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
