Exporting ioToST from Control.Monad.ST

David Feuer david.feuer at gmail.com
Thu Jul 20 17:57:35 UTC 2017

IO and ST RealWorld are indeed represented the same--in today's GHC. It
would be possible to implement the same ST interface differently (e.g., as
an operational monad). Adding ioToST to the public interface commits not
only GHC, but also future Haskell implementations, to a similar

Note: I recently noticed a real difference between IO and ST with regard to
strictness analysis. In IO,

m >>= undefined

is *not* bottom: it may perform an observable action. In ST, it is bottom;
anything it mutates is guaranteed to vanish in a puff of smoke.

So assuming that these have the same representation actually introduces
some complications for optimization.

On Jul 20, 2017 1:36 PM, "Andrew Martin" <andrew.thaddeus at gmail.com> wrote:

My understanding is that `ST RealWorld` and `IO` are genuinely the same
thing. But I'd want someone with better understanding to corroborate that

On Thu, Jul 20, 2017 at 12:02 PM, David Feuer <david.feuer at gmail.com> wrote:

> This seems to commit to ST and IO really being the same. Does stToIO
> already make this commitment? I can't tell, but if not, I oppose making
> that commitment in the "public" interface.
> On Jul 20, 2017 11:51 AM, "Andrew Martin" <andrew.thaddeus at gmail.com>
> wrote:
> There's a function stToIO that is defined in GHC.IO and exported from
> Control.Monad.ST. There's another function, ioToST, that's also defined
> in IO, but it isn't exported from Control.Monad.ST. I propose that it be
> exported from Control.Monad.ST.
> --
> -Andrew Thaddeus Martin
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170720/8c1dd864/attachment.html>

More information about the Libraries mailing list