[Haskell] Re: IO == ST RealWorld
Jan-Willem Maessen
jmaessen at alum.mit.edu
Tue Feb 21 10:31:37 EST 2006
On Feb 20, 2006, at 5:57 PM, Ben Rudiak-Gould wrote:
> John Meacham wrote:
>> 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)
>
> Supposing you had
>
> data STResult s a where
> FailIO :: World__ IOWorld__ -> IOError -> STResult IOWorld__ a
> JustST :: World__ s -> a -> STResult s a
>
> could static analysis then eliminate the test for FailIO in ST code?
Only in a very limited way. Nothing can be done with the following
code:
if checkOK then
JustST ...
else
FailIO ...
So we can "optimize away" the JustST from failure-free IO
computations, but anything which might possibly fail is problematic.
Sadly, IO computations which perform any actual IO must usually admit
the possibility of failure, and you actually degrade performance in
practice by wrapping things up in an extra constructor, at least
compared to a mechanism where failure is propagated by invoking an
alternate continuation. (You also have to carefully engineer the
strictness of "bind" and of every IO construct in order to make sure
that eliminating the constructor is actually a valid transformation
and that things don't deadlock, but that's a simple matter of
programming...)
-Jan-Willem Maessen (who tried a similar experiment back in 1994 or so.)
> It would be pretty cool if the answer was yes, since it would mean
> that merging IO and ST would be an optimization instead of a
> pessimization (the test could also be omitted in IO code that uses
> only the ST subset). In jhc I suppose this would have to happen
> late in compilation, when you eliminate unused type parameters.
>
> Actually, won't the test for FailIO always be eliminated by the
> existing points-to analysis?
>
> -- Ben
>
> _______________________________________________
> Haskell mailing list
> Haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
More information about the Haskell
mailing list