Re: 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  
Date: 11/21/17  12:43 PM  (GMT-05:00) To: ghc-devs  
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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC] #14490: TTG Snags

[Alan & Kim Zimmerman]

Yes, but it is not feasible before GHC 8.6, due to needing GHC >= 8.2 for
bootstrapping.



On 22 November 2017 at 15:26, GHC  wrote:

> #14490: TTG Snags
> -+--
> ---
> Reporter:  alanz |Owner:  (none)
> Type:  bug   |   Status:  new
> Priority:  normal|Milestone:
>Component:  Compiler  |  Version:  8.3
>   Resolution:| Keywords:
> Operating System:  Unknown/Multiple  | Architecture:
>  |  Unknown/Multiple
>  Type of failure:  None/Unknown  |Test Case:
>   Blocked By:| Blocking:
>  Related Tickets:  #14482|  Differential Rev(s):
>Wiki Page:|
>   ImplementingTreesThatGrow  |
> -+--
> ---
>
> Comment (by Shayan-Najd):
>
>  > So making a Data instance per concrete version may be the best way to
>  go. Plan B.
>
>  Regardless of the GHC version we use, the question is whether Plan B
>  really fixes the build-time problem. Can we test it?
>
> --
> Ticket URL: 
> GHC 
> The Glasgow Haskell Compiler
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHCi recompilation avoidance UI

[Simon Marlow]

David,

Perhaps it would be good to defer changing the behaviour of :load *M (I
believe you that it's hard, that code is quite convoluted) and for now just
focus on making GHCi able to load compiled object code again, which I think
is a much simpler problem?

Cheers
Simon


On 21 November 2017 at 21:49, David Feuer  wrote:

> 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 want.
> I believe it's fairly clear that, as Simon M wrote,
>
> > [W]e'll want at least -fignore-optim-changes to be the default, so that
> GHCi
> > does the expected thing when you have compiled object files.
>
> Based on Simon PJ's comment, I believe we want to *continue* to discard
> optimization flags when -fobject-code is not enabled. As for my suggestion
> in (2),
> I spent the last couple hours attempting to figure out what would be
> necessary
> to allow :load *M to load a module  interpreted even when using
> -fobject-code,
> but found myself utterly lost in the module loading logic. I see that the
> IIModule
> constructor is deeply involved in this, but I haven't been able to figure
> out
> where/how that interacts with -fobject-code to determine whether the module
> will actually be loaded interpreted or compiled. Can someone give me a
> clue?
>
> On Thursday, November 2, 2017 10:21:07 AM EST Simon Marlow wrote:
> > On 31 October 2017 at 15:42, David Feuer  wrote:
> >
> > > Changes in GHC 8.2.1 lead to a lot of recompilation, because GHCi now
> > > refuses to load optimized
> > > code unless -fobject-code (and optimization flags) are enabled. I
> propose
> > > the following slight
> > > modification to https://ghc.haskell.org/trac/
> ghc/ticket/13604#comment:48
> > >
> > > 1. Optimization flags (except -O0) imply -fobject-code. This ensures
> that
> > > GHC respects optimization flags regardless of --interactive.
> > >
> > > 2. Even when -fobject-code is on, :load *M will load M as bytecode.
> This
> > > provides the "escape hatch" from -fobject-code that you need to use
> > > debugging features, etc.
> > >
> >
> > Yes, I think this is probably what we want. I'm not sure how smooth it
> will
> > be to implement though.
> >
> >
> > > 3. New -fignore-optim-changes and -fignore-hpc-changes (​​Phab:D4123)
> > > flags should enable users to put together object code and bytecode with
> > > diverse optimization levels/options and HPC options while still
> updating
> > > automatically based on source changes and whether profiling is enabled.
> > >
> >
> > As I mentioned on the diff, I think we'll want at least
> > -fignore-optim-changes to be the default, so that GHCi does the expected
> > thing when you have compiled object files.
> >
> > Cheers
> > Simon
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs