Can strict ST break referential transparency?

[Yuras Shumovich]

22-11-2017, Срд а 15:37 -0500, David Feuer напісаў:
> If there is indeed a problem, I suspect the right way to fix it is to
> make sure that no partially evaluated thunk is ever resumed twice.
> Inter-thread exceptions are presumably rare enough that we don't have
> to worry *too* much about their cost.

Sounds reasonable. But probably it already works that way? Though it
doesn't seem to be covered in the papers, and looks like nobody knows
an answer to my question. It makes me worry a bit.

On the other hand, right now resuming frozen thunk usually
crashes/hangs as discovered in #14497. Nobody noticed that so far in
the wild, so probably the subject is just a dark corner case, not worse
the efforts.

> 
> 
> David FeuerWell-Typed, LLP
> -------- Original message --------From: Yuras Shumovich <shumovichy at g
> mail.com> Date: 11/21/17  12:43 PM  (GMT-05:00) To: ghc-devs <ghc-dev
> s at haskell.org> Subject: Can strict ST break referential
> transparency? 
> 
> Hello,
> 
> I was evaluating a possibility that linear types can break
> referential
> transparency [1], exactly like lazy ST [2].
> 
> But on the way I realized that even strict ST may suffer from the
> same
> issue. If ST computation is interrupted by e.g. async exception,
> runtime will "freeze" it at the point where it was interrupted [3].
> 
> So the question: is the "freezed" computation just a normal thunk?
> Note
> that the runtime doesn't guarantee that a thunk will be evaluated
> only
> once [4]. If the "freezed" thunk captures e.g. STRef, and will be
> evaluated twice, its effect could become observable from outside,
> just
> like in case of lazy ST.
> 
> I tried to check the theory by stress testing RTS. Unfortunately I
> immediately discovered a runtime crash [5], which is probably not
> related to my question.
> 
> Hope someone will be able to clarify things for me.
> 
> Thanks,
> Yuras.
> 
> [1] https://github.com/ghc-proposals/ghc-proposals/pull/91#issuecomme
> nt
> -345553071
> [2] https://ghc.haskell.org/trac/ghc/ticket/14497
> [3] See section 8 there: https://www.microsoft.com/en-us/research/wp-
> co
> ntent/uploads/2016/07/asynch-exns.pdf
> [4] https://www.microsoft.com/en-us/research/wp-content/uploads/2005/
> 09
> /2005-haskell.pdf
> [5] https://ghc.haskell.org/trac/ghc/ticket/14497
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs