Can strict ST break referential transparency?

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


David FeuerWell-Typed, LLP
-------- Original message --------From: Yuras Shumovich <shumovichy at gmail.com> Date: 11/21/17  12:43 PM  (GMT-05:00) To: ghc-devs <ghc-devs 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#issuecomment
-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171122/5f0a8e04/attachment.html>