Can strict ST break referential transparency?

[Simon Peyton Jones]

If the conclusion is that there's a bug here, could someone distil the example into a ticket?

Thanks

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ben
| Gamari
| Sent: 23 November 2017 15:20
| To: Yuras Shumovich <shumovichy at gmail.com>; ghc-devs <ghc-
| devs at haskell.org>
| Subject: Re: Can strict ST break referential transparency?
| 
| Yuras Shumovich <shumovichy at gmail.com> writes:
| 
| > Hello,
| >
| Hello,
| 
| Sorry for the late reply; this required a bit of reflection. The
| invariants surrounding the suspension of ST computations is a rather
| delicate and poorly documented area.
| 
| I believe the asynchronous exception case which you point out is
| precisely #13615. The solution there was, as David suggests, ensure that
| no resulting thunk could be entered more than once by a very strict
| blackholing protocol. Note that this isn't normal "eager" blackholing
| protocol, which still might allow multiple entrancy. It's rather a more
| strict variant, requiring two atomic operations.
| 
| I can't be certain that there aren't more cases like this, but I suspect
| not since most asynchronous suspensions where the resulting thunk might
| "leak" back into the program go through the raiseAsync codepath that was
| fixed in #13615.
| 
| Cheers,
| 
| - ben