Exporting ioToST from Control.Monad.ST

[David Feuer]

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
representation.

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
claim.

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>