[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