RealWorld

[Simon Marlow]

> More suggestions:
>=20
> 1) Pursuing the view that this thing identifies a special ST-style
> state included in the IO monad, we could view the IO state stuff as
> a special case of the ST stuff, changing
>=20
> 	newtype IORef a =3D IORef (STRef IOState a)
> 	newtype IOArray i e =3D IOArray (STArray IOState i e)
> 	newtype IOUArray i e =3D IOUArray (STUArray RealWorld i e)
>=20
> (currently exported opaquely) to
>=20
> 	type IORef =3D STRef IOState
> 	type IOArray =3D STArray IOState
> 	type IOUArray =3D STUArray IOState
>=20
> so that there would only be one type of reference.

This constrains the implementations of IORef and STRef to be the same
(obviously).  I can't immediately see any benefit from using different
implementations for these two types, so maybe it's not an issue.

> 2) For additional genericity, define a class
>=20
> 	class MonadST s m | m -> s where
> 		liftST :: Control.Monad.ST.ST s a -> m a
>=20
[snip]
>=20
> then all the operations lift to all such monads, e.g.
>=20
> 	readSTRef :: MonadST s m =3D> STRef s a -> m a
> 	readSTRef r =3D liftST (Data.STRef.readSTRef r)

Same argument as for MonadIO:  I don't like the idea of generalising all
the ST functions, and just generalising some of them would be
inconsistent, so don't generalise any of them.  Providing MonadST and
liftST is fine, though.

Cheers,
	Simon