Re: Can strict ST break referential transparency?

Sorry, link [2] meant to be https://ghc.haskell.org/trac/ghc/ticket/11760 21-11-2017, Аўт а 20:43 +0300, Yuras Shumovich напісаў: > 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

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

Re: GHCi recompilation avoidance UI

I started digging back into this today, particularly considering Simon PJ's view that it's a bit odd for optimization flags to imply -fobject-code (specifically because we could potentially support optimization for the bytecode interpreter some day). I'm left even more lost about exactly what we

[ANNOUNCE] GHC 8.2.2 released

=== The Glasgow Haskell Compiler -- version 8.2.2 === The GHC Team is pleased to announce a new minor release of GHC. This release builds on the performance and stability

Re: GHCi recompilation avoidance UI

David Feuer writes: > I started digging back into this today, particularly considering Simon PJ's > view > that it's a bit odd for optimization flags to imply -fobject-code > (specifically > because we could potentially support optimization for the bytecode > interpreter

Re: [ANNOUNCE] GHC 8.2.2 released

Ben Gamari writes: > A thorough list of the changes in the release can be found in the release > notes, > > https://haskell.org/ghc/docs/8.2.2/html/users_guide/release-8-2-2.html > For the record this link was incorrect. It should be