| -----Original Message-----
| From: Ross Paterson [mailto:ross@soi.city.ac.uk]
| Sent: 18 September 2003 10:20
| To: Simon Peyton-Jones
| Cc: Alastair Reid; Simon Marlow; libraries(a)haskell.org
| Subject: Re: RealWorld
|
| 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).
Aha. I hadn't realised that you want to expose IORef as an STRef, but
not the IO monad itself.
I certainly don't object to that, but I'm not sure of all the
implications. For example, at the moment one could have
class MRef m r | m -> r, r -> m where
new :: a -> m (r a)
read :: r a -> m a
write :: r a -> a -> m ()
instance MRef IO IORef where ...
instance MRef (ST s) (STRef s) where ...
I don't think that'll be legal if IORef = STRef IORegion, because the
"r->m" dependency becomes ambiguous. So we'd have to lose the "r->m"
dependency.
Maybe that's ok. (I don't think MRef currently exists in the
libraries.) But it's an example of a consequence of the choice you
suggest.
Simon
|
| > 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.
