RealWorld

[Ross Paterson]

On Thu, Sep 18, 2003 at 08:56:40AM +0100, Simon Peyton-Jones wrote:
> Is the proposal that the library design exposes to the programmer the
> following type synonyms:
> 
> 	type IO a = ST IORegion a
> 	type IORef a = STRef IORegion a

The proposal is to expose

	type IORef = STRef IORegion
	type IOArray = STArray IORegion
	type IOUArray = STUArray IORegion

(modulo the name of IORegion) but to keep IO opaque.  I think that while
IO includes state, it is not itself a state monad (because the "state"
there can be changed by other agents at the same time).

> I think it is sound to do so.  The advantage would be that newIORef and
> newSTRef would be the same (newRef, perhaps); ditto readRef, writeRef
> etc.

If IO is opaque, then we have

	newIORef = stToIO . newSTRef

etc.  It's not quite as generic as your version, but it is a conceptual
simplification, and it does allow generic classes like

	class MonadST s m | m -> s where
		liftST :: Control.Monad.ST.ST s a -> m a

with instances for IO, both ST's and various constructed monads, so we
could have the likes of

	readSTRef' :: MonadST s m => STRef s a -> m a
	readSTRef' r = liftST (Data.STRef.readSTRef r)

My problem with exposing the GHC implementation of IO is that I don't
think it's the Truth, and Haskell has a record of punishing untruths
sooner or later.

> I think this would be fine for GHC.  It might not be fine for Hugs
> because they implement IO and ST differently I think.  No idea about
> NHC.

NHC doesn't have ST (rank-2 types).  In Hugs, they are now

	newtype IO a = IO ((a -> IOResult) -> IOResult)
	newtype ST s a = ST (forall r. (a -> r) -> r)

	primitive newIORef   "newRef" :: a -> IO (IORef a)
	primitive newSTRef   "newRef" :: a -> ST s (STRef s a)

But I'm not proposing that this be exposed.

> Or, alternatively, is the question something to do with the internals of
> the library, of interest to implementers but not to users of the
> library?  Or is it just to do with the type of stToIO, which should be
> 
> 	stToIO :: ST IORegion a -> IO a

It's more a matter of making IORegion work a bit harder since we have to
put it in the interface anyway.