Re: [Haskell] IO == ST RealWorld
Axel Simon <[EMAIL PROTECTED]> writes:
> 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
I think it would be unimplementable.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] IO == ST RealWorld
On Mon, Jan 23, 2006 at 09:55:39PM +0100, Twan van Laarhoven 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. ST doesn't have exceptions which IO does. It would be no good to make ST pay for the cost of exception handling. GHC handles them behind the scenes (I think?) but in jhc they are explicit and IO is defined as follows: > data World__ > > data IOResult a = FailIO World__ IOError | JustIO World__ a > newtype IO a = IO (World__ -> IOResult a) I belive other implementations have used continuations for IO as well. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] IO == ST RealWorld
On Tue, Jan 24, 2006 at 06:40:38PM +, Ben Rudiak-Gould wrote: > Ross Paterson wrote: > >But IO isn't a state monad: others are concurrently changing the world > >without waiting for my Haskell program to terminate. > > I think that closed-world behavior should be treated as a property of > runST, not of the ST monad operations. Otherwise your IORef = STRef > IORegion proposal doesn't work either, because e.g. > > myId :: STRef s a -> a -> ST s a > myId r x = writeSTRef r x >> readSTRef r > > doesn't necessarily return its second argument when lifted to IO, in the > presence of multithreading. Ouch! Being able to do that kind of reasoning in ST is really important. I'd rather sacrifice stToIO than lose that. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] IO == ST RealWorld
Ross Paterson wrote: But IO isn't a state monad: others are concurrently changing the world without waiting for my Haskell program to terminate. I think that closed-world behavior should be treated as a property of runST, not of the ST monad operations. Otherwise your IORef = STRef IORegion proposal doesn't work either, because e.g. myId :: STRef s a -> a -> ST s a myId r x = writeSTRef r x >> readSTRef r doesn't necessarily return its second argument when lifted to IO, in the presence of multithreading. This philosophical objection to IO = ST IORegion has come up before, and I think it's approaching the problem exactly backwards. If IO = ST IORegion works in practice and is useful in practice, then we ought to be coming up with a theory of IO/ST that supports it, not rejecting it on the basis of a theory that doesn't support it. -- Ben ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] IO == ST RealWorld
On Tue, 2006-01-24 at 09:17 +, 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
Re: [Haskell] IO == ST RealWorld
On Mon, Jan 23, 2006 at 09:55:39PM +0100, Twan van Laarhoven 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. But IO isn't a state monad: others are concurrently changing the world without waiting for my Haskell program to terminate. Some compilers use a state monad to enforce sequencing, but a continuation monad or resumption monad would work just as well. However IO does include a state monad, so one could define (using IORegion instead of the presumptuous RealWorld): type IORef = STRef IORegion type IOArray = STArray IORegion type IOUArray = STUArray IORegion newIORef = stToIO . newSTRef ... ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] IO == ST RealWorld
| 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? Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] IO == ST RealWorld
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. Twan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
