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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
