Re: The GHC 8.0 feature freeze is coming

Is Simon's remote GHCi patch planned to go in before the fork? I'm still working on upgrading GHCJS to work with the master branch, but I haven't quite finished yet. This change would clearly require some restructuring of GHCJSi and Template Haskell in GHCJS, and I'm not sure if a week is enough

Re: FW: [Diffusion] [Build Failed] rGHC52b02e66025f: Comments only (isIrrefutablePat)

I've gathered some numbers (most recent commits last): 290def72f54db7969258b4541aaefc87b54ce448 44354749424 Implement warnings for Semigroups as parent of Monoid afb721390cd506f09ce9f04aa3fb19324c2ae5a0 44354739384 MkId: Typos in comments 14d0f7f1221db758cd06a69f53803d9d0150164a 44354739384

Re: Warning suppression pragmas

Эдгар Жаворонков writes: > Hello devs! > > I am trying to implement some kind of local warnings suppresion and i need > some help. > > I want to use a pragma to mark functions so compiler won't throw warnings > from them. I defined my pragma in lexer, parser and added

Re: The GHC 8.0 feature freeze is coming

Luite Stegeman writes: > Is Simon's remote GHCi patch planned to go in before the fork? I'm still > working on upgrading GHCJS to work with the master branch, but I haven't > quite finished yet. This change would clearly require some restructuring of > GHCJSi and Template

Re: The GHC 8.0 feature freeze is coming

My 2c, I would love to see the remote GHCi patch land for 8.0. It is a big change though. Alan On Thu, Dec 3, 2015 at 4:31 PM, Austin Seipp wrote: > On Thu, Dec 3, 2015 at 7:50 AM, Ben Gamari wrote: >> Luite Stegeman writes: >>

RE: The GHC 8.0 feature freeze is coming

Simon Peyton Jones writes: > | HEAD is sadly currently broken for unrelated reasons which I am > | working on resolving at the moment. I'll send a message to ghc-devs > | when I've pushed my fix. > > Does that mean I should not pull for now? Which means I can't push

RE: The GHC 8.0 feature freeze is coming

| HEAD is sadly currently broken for unrelated reasons which I am | working on resolving at the moment. I'll send a message to ghc-devs | when I've pushed my fix. Does that mean I should not pull for now? Which means I can't push either. Simon

Re: The GHC 8.0 feature freeze is coming

On Thu, Dec 3, 2015 at 7:50 AM, Ben Gamari wrote: > Luite Stegeman writes: > >> Is Simon's remote GHCi patch planned to go in before the fork? I'm still >> working on upgrading GHCJS to work with the master branch, but I haven't >> quite finished yet.

Re: tyVarsOfTypeAcc

Hi Richard, I've introduced tyVarsOfTypeAcc recently and the main reason was to get deterministic order (part of #4012) of free variables in places that require it, like abstracting type variables when floating out expressions. It does a bit more than tyVarsOfType, but it's algorithmically better

Re: tyVarsOfTypeAcc

Bartosz left a note in the diff about it being faster this way: https://github.com/niteria/deterministic-fvs/blob/master/results.txt#L83-L89 But yeah, I would have also thought it better eta-reduced. On Thu, Dec 3, 2015 at 10:43 AM, Richard Eisenberg wrote: > Hi devs, > >

Re: The GHC 8.0 feature freeze is coming

Based on my cursory look at the patch, I think it's unlikely to break existing functionality in subtle ways. So I'm OK with trying to ship it in 8.0 Edward Excerpts from Simon Marlow's message of 2015-12-03 09:50:37 -0800: > On 03/12/2015 13:50, Ben Gamari wrote: > > Luite Stegeman

Re: Bad interface file

On 27/11/2015 15:31, Simon Peyton Jones wrote: Can anyone confirm that Trac #11122 is fixed in HEAD? When I try to reproduce it, I tried this, *with a freshly-built HEAD* cabal install parsec --with-ghc=/home/simonpj/5builds/HEAD-5/inplace/bin/ghc-stage2 But that fails as below, with a

Re: The GHC 8.0 feature freeze is coming

On 03/12/2015 13:50, Ben Gamari wrote: Luite Stegeman writes: Is Simon's remote GHCi patch planned to go in before the fork? I'm still working on upgrading GHCJS to work with the master branch, but I haven't quite finished yet. This change would clearly require some

tyVarsOfTypeAcc

Hi devs, I'm (once again) merging master into my type=kind branch. I see that we now have tyVarsOfTypeAcc :: Type -> FV, distinct from tyVarsOfType :: Type -> TyVarSet. I trust that this new version is more performant. However, I have a question: in the implementation of these functions, the