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 Build system: Add stage specific SRC_HC_(WARNING_)OPTS 6dce643d1981f1ecba2b38f5932720385999244b 44354736328 Fix grammar and typo in TcTyDecls 36c1247846bbbc1af939c098660ce27ddaa36a0d 44354706024 Remove duplicated line 44c3e3768e28199468d20b25db055d22c310 44354770368 Fix warning about unused pattern variable b432e2f39c095d8acbb0cfcc63bd08436c7a3e49 44354770368 Make the determinism tests more robust 1e041b7382b6aa329e4ad9625439f811e0f27232 44420002848 Refactor treatment of wildcards 218fdf92370021b900af1e78323764cceb7ac609 44420193216 Make the order of fixities in the iface file deterministic 741f837d652fd00671614d52a6cb16fbc3758480 44489177576 Implement more deterministic operations and document them I've collected them on my machine and they differ from what harbormaster reports, the last commit measured by harbormaster is 44728541608. The target value is 4062434 +/-10% and my numbers suggest it's been steadily climbing out of that range. I don't know what this test measures exactly, does it depend on the number of haddock comments in GHC's source? Cheers, Bartosz 2015-12-02 17:19 GMT+00:00 Ben Gamari : > Simon Peyton Jones writes: > > > Haddock is a constant mystery. > > > > I added five lines of comments to GHC's source code, and one of the > > Haddock performance tests fails (see below). That's all the patch > > contains. > > > Don't worry, I think it's niteria's patch that is to blame here. > Diffusion is a convenient way to check the state of the tree [1]. > > Cheers, > > - Ben > > [1] https://phabricator.haskell.org/diffusion/GHC/ > > ___ > 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: 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 type signature in
> HsBinds.hs. And i am stuck. I don't know what to do. What should i consider
> doing further?
>
I think it would be helpful to focus on further elaborating the
specification before we move into the implementation. There are still a
number of open questions about the design that the wiki page doesn't yet
address.
For instance, you should explicitly specify,
* What are the identifiers that appear after the `SUPPRESS` token?
* What exactly does the pragma apply to? For instance, if I have a case
like,
hello :: Int -> Int
{-# SUPPRESS some-warning #-}
helloAgain :: Type -> AnotherType
hello = (+1)
helloAgain = error "42"
or even just
hello = (+1)
{-# SUPPRESS another-warning #-}
helloAgain = error "oops"
What do you expect to happen? The behavior of the pragma in both of
these cases should be unambiguously stated in the specification.
* An concrete use-case motivating the change (preferably with examples
showing how the proposed syntax would address the motivation)
I know this sounds repetitive, but the act of writing down a proposal
will help you immensely when you do move on to implementing your ideas.
Thanks for your persistence.
Cheers,
- Ben
signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 to test the changes. Also the recent removal of boot file merging reintroduces a problem with that I'm not sure can be fixed without adding a new hook. What's the policy on adding hooks or GHC API tweaks after the freeze? cheers, Luite On Wed, Dec 2, 2015 at 7:34 PM Ben Gamari wrote: > tl;dr: feature freeze is imminent; get any remaining patches in ASAP. > > > Hello all, > > The GHC 8.0 release cycle is quickly approaching its conclusion. While > there are a few patches still outstanding (most notably the no-kinds > branch to which we owe the major version number bump), most everything > else has at this point been merged. > > If you are still sitting on a patch then please post it for review as > soon as possible. We will enter a formal feature freeze within the next > week. If things go according to plan we will have be able to fork the > 8.0 branch shortly thereafter and have a release candidate within two > weeks. > > Thanks to everyone who has contributed to this release! > > Cheers, > > - Ben > ___ > 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: 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 either. > No, feel free to pull and push. The problem is that Harbormaster builds are failing to validate due to changes in haddock allocations leading to failures of testsuite stat tests [1]. Sadly I'm unable to reproduce this locally but I just pushed what I believe should be a fix. Sadly now we need to work through the fall-out from George's patch. Cheers, - Ben [1] https://phabricator.haskell.org/harbormaster/build/8442/ signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 Haskell in GHCJS, and I'm not sure if a week is enough > to test the changes. Also the recent removal of boot file merging > reintroduces a problem with that I'm not sure can be fixed without adding a > new hook. > Simon, what do you think about this? I'm a bit worried that this patch is quite late and breaks users like Luite. Nevertheless, I am willing to hear arguments for merging. > What's the policy on adding hooks or GHC API tweaks after the freeze? > We'll need to work that out when we get to that point. It largely depends upon how confined and "safe" a change appears to be. That being said, given how much other churn has happened for this release, I don't think we want to be sloppy with merge discipline this time around. Austin, what do you think? Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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. This change would clearly require some restructuring of >> GHCJSi and Template Haskell in GHCJS, and I'm not sure if a week is enough >> to test the changes. Also the recent removal of boot file merging >> reintroduces a problem with that I'm not sure can be fixed without adding a >> new hook. >> > Simon, what do you think about this? > > I'm a bit worried that this patch is quite late and breaks users like > Luite. Nevertheless, I am willing to hear arguments for merging. I think this is one we're best off leaving in HEAD. It's a very large change, and I'm a bit scared of bringing it in right at the finish line, so to speak. I think it might be best to just get it in sometime after the branch IMO... >> What's the policy on adding hooks or GHC API tweaks after the freeze? >> > We'll need to work that out when we get to that point. It largely > depends upon how confined and "safe" a change appears to be. That being > said, given how much other churn has happened for this release, I don't > think we want to be sloppy with merge discipline this time around. > > Austin, what do you think? > > Cheers, > > - Ben > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > Hrm. If possible I would like to avoid any breaking changes past the first RC, which has normally been my policy... Generally it's just easier for everyone this way and people typically don't like too many mid-flight changes, once things are in RC-mode. That said, if it's something game-breaking for, say, GHCJS, I'd be open to it. But we should try to fix it ASAP, not in the middle of February. So it would be best if we could find out what hooks or tweaks we needed Very Soon. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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: >> >>> 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 >>> to test the changes. Also the recent removal of boot file merging >>> reintroduces a problem with that I'm not sure can be fixed without adding a >>> new hook. >>> >> Simon, what do you think about this? >> >> I'm a bit worried that this patch is quite late and breaks users like >> Luite. Nevertheless, I am willing to hear arguments for merging. > > I think this is one we're best off leaving in HEAD. It's a very large > change, and I'm a bit scared of bringing it in right at the finish > line, so to speak. I think it might be best to just get it in sometime > after the branch IMO... > >>> What's the policy on adding hooks or GHC API tweaks after the freeze? >>> >> We'll need to work that out when we get to that point. It largely >> depends upon how confined and "safe" a change appears to be. That being >> said, given how much other churn has happened for this release, I don't >> think we want to be sloppy with merge discipline this time around. >> >> Austin, what do you think? >> >> Cheers, >> >> - Ben >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > Hrm. If possible I would like to avoid any breaking changes past the > first RC, which has normally been my policy... Generally it's just > easier for everyone this way and people typically don't like too many > mid-flight changes, once things are in RC-mode. > > That said, if it's something game-breaking for, say, GHCJS, I'd be > open to it. But we should try to fix it ASAP, not in the middle of > February. So it would be best if we could find out what hooks or > tweaks we needed Very Soon. > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > ___ > 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: 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 restructuring of GHCJSi and Template Haskell in GHCJS, and I'm not sure if a week is enough to test the changes. Also the recent removal of boot file merging reintroduces a problem with that I'm not sure can be fixed without adding a new hook. Simon, what do you think about this? I'm a bit worried that this patch is quite late and breaks users like Luite. Nevertheless, I am willing to hear arguments for merging. It doesn't have to go in, but I think it would be nice. I'd like to have it out for at least one major release in a disabled-by-default state so that we can experiment with it. But as far as my particular goals for this feature are concerned, I'll backport the patch to 7.10 and use it in our local GHC build at Facebook regardless. Luite - the hooks you use are still intact, so I don't think you have to do any major restructuring in GHCJS until you're ready. What I've implemented will almost certainly need work to be usable or shareable with GHCJS, and it's not clear to me exactly what the changes will look like, but for the time being I thought the changes should not impact GHCJS's implementation of TH & GHCi. I could be wrong though, if so please let me know how it breaks you. Cheers, Simon What's the policy on adding hooks or GHC API tweaks after the freeze? We'll need to work that out when we get to that point. It largely depends upon how confined and "safe" a change appears to be. That being said, given how much other churn has happened for this release, I don't think we want to be sloppy with merge discipline this time around. Austin, what do you think? Cheers, - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 bizarre “bad interface file” error. Does anyone have a clue about what’s happening? Does it work for you? You probably have .hi files generated by a previous version of HEAD installed under your ~/.cabal/lib, and the current HEAD chokes on them. Try rm -rf ~/.cabal/lib/*ghc-7.11* Cheers Simon Simon cabal install parsec --with-ghc=/home/simonpj/5builds/HEAD-5/inplace/bin/ghc-stage2 Resolving dependencies... Configuring mtl-2.2.1... Building mtl-2.2.1... Preprocessing library mtl-2.2.1... [ 1 of 22] Compiling Control.Monad.Writer.Class ( Control/Monad/Writer/Class.hs, dist/build/Control/Monad/Writer/Class.o ) [ 2 of 22] Compiling Control.Monad.State.Class ( Control/Monad/State/Class.hs, dist/build/Control/Monad/State/Class.o ) [ 3 of 22] Compiling Control.Monad.Reader.Class ( Control/Monad/Reader/Class.hs, dist/build/Control/Monad/Reader/Class.o ) [ 4 of 22] Compiling Control.Monad.RWS.Class ( Control/Monad/RWS/Class.hs, dist/build/Control/Monad/RWS/Class.o ) [ 5 of 22] Compiling Control.Monad.Identity ( Control/Monad/Identity.hs, dist/build/Control/Monad/Identity.o ) [ 6 of 22] Compiling Control.Monad.Error.Class ( Control/Monad/Error/Class.hs, dist/build/Control/Monad/Error/Class.o ) [ 7 of 22] Compiling Control.Monad.Cont.Class ( Control/Monad/Cont/Class.hs, dist/build/Control/Monad/Cont/Class.o ) [ 8 of 22] Compiling Control.Monad.Trans ( Control/Monad/Trans.hs, dist/build/Control/Monad/Trans.o ) [ 9 of 22] Compiling Control.Monad.Error ( Control/Monad/Error.hs, dist/build/Control/Monad/Error.o ) [10 of 22] Compiling Control.Monad.Except ( Control/Monad/Except.hs, dist/build/Control/Monad/Except.o ) [11 of 22] Compiling Control.Monad.List ( Control/Monad/List.hs, dist/build/Control/Monad/List.o ) [12 of 22] Compiling Control.Monad.RWS.Lazy ( Control/Monad/RWS/Lazy.hs, dist/build/Control/Monad/RWS/Lazy.o ) [13 of 22] Compiling Control.Monad.RWS ( Control/Monad/RWS.hs, dist/build/Control/Monad/RWS.o ) [14 of 22] Compiling Control.Monad.Reader ( Control/Monad/Reader.hs, dist/build/Control/Monad/Reader.o ) [15 of 22] Compiling Control.Monad.RWS.Strict ( Control/Monad/RWS/Strict.hs, dist/build/Control/Monad/RWS/Strict.o ) [16 of 22] Compiling Control.Monad.State.Lazy ( Control/Monad/State/Lazy.hs, dist/build/Control/Monad/State/Lazy.o ) [17 of 22] Compiling Control.Monad.State ( Control/Monad/State.hs, dist/build/Control/Monad/State.o ) [18 of 22] Compiling Control.Monad.State.Strict ( Control/Monad/State/Strict.hs, dist/build/Control/Monad/State/Strict.o ) [19 of 22] Compiling Control.Monad.Writer.Lazy ( Control/Monad/Writer/Lazy.hs, dist/build/Control/Monad/Writer/Lazy.o ) [20 of 22] Compiling Control.Monad.Writer ( Control/Monad/Writer.hs, dist/build/Control/Monad/Writer.o ) [21 of 22] Compiling Control.Monad.Writer.Strict ( Control/Monad/Writer/Strict.hs, dist/build/Control/Monad/Writer/Strict.o ) [22 of 22] Compiling Control.Monad.Cont ( Control/Monad/Cont.hs, dist/build/Control/Monad/Cont.o ) In-place registering mtl-2.2.1... Creating package registration file: /tmp/pkgConf-mtl-2.253500.1 Installing library in /home/simonpj/.cabal/lib/x86_64-linux-ghc-7.11.20151125/mtl_29yPYQfz4VvKtYIFBb0Wdp Registering mtl-2.2.1... Installed mtl-2.2.1 Downloading text-1.2.1.3... Failed to install text-1.2.1.3 cabal: Error: some packages failed to install: parsec-3.1.9 depends on text-1.2.1.3 which failed to install. text-1.2.1.3 failed while downloading the package. The exception was: : hGetBufSome: resource vanished (Connection reset by peer) simonpj@cam-05-unx:~/5builds/HEAD-5$ cabal install parsec --with-ghc=/home/simonpj/5builds/HEAD-5/inplace/bin/ghc-stage2 Resolving dependencies... Downloading text-1.2.1.3... Configuring text-1.2.1.3... Building text-1.2.1.3... Preprocessing library text-1.2.1.3... [ 1 of 44] Compiling Data.Text.Internal.Read ( Data/Text/Internal/Read.hs, dist/build/Data/Text/Internal/Read.o ) [ 2 of 44] Compiling Data.Text.Internal.Encoding.Utf32 ( Data/Text/Internal/Encoding/Utf32.hs, dist/build/Data/Text/Internal/Encoding/Utf32.o ) [ 3 of 44] Compiling Data.Text.Internal.Builder.RealFloat.Functions ( Data/Text/Internal/Builder/RealFloat/Functions.hs, dist/build/Data/Text/Internal/Builder/RealFloat/Functions.o ) [ 4 of 44] Compiling Data.Text.Internal.Builder.Int.Digits ( Data/Text/Internal/Builder/Int/Digits.hs, dist/build/Data/Text/Internal/Builder/Int/Digits.o ) [ 5 of 44] Compiling Data.Text.Encoding.Error ( Data/Text/Encoding/Error.hs, dist/build/Data/Text/Encoding/Error.o ) Data/Text/Encoding/Error.hs:3:14: warning: ‘Data.Text.Encoding.Error’ is marked as Trustworthy but has been inferred as safe! [ 6 of 44] Compiling Data.Text.Intern
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 three extra FV parameters (fv_cand in_scope acc) are bound and passed each time. Why? I've always understood that eta-reducing in function definitions is better than expanding. Or is this just a style choice? Thanks, Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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, > > 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 three extra FV > parameters (fv_cand in_scope acc) are bound and passed each time. > > Why? > > I've always understood that eta-reducing in function definitions is better > than expanding. Or is this just a style choice? > > Thanks, > Richard > ___ > 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: 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 (it avoids set union) and in the end it comes out about equal in terms of performance on GHC tests. The reason for eta-expanding is performance, and I wrote a note [1] about it. I've also run some isolated benchmarks [2] if you're interested. [1] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/utils/FV.hs;43a31fe4c0cc0f72dfe9e0c96e1576f5cfba6e19$105-140 [2] https://github.com/niteria/deterministic-fvs/ Cheers, Bartosz 2015-12-03 18:43 GMT+00:00 Richard Eisenberg : > 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 three extra > FV parameters (fv_cand in_scope acc) are bound and passed each time. > > Why? > > I've always understood that eta-reducing in function definitions is better > than expanding. Or is this just a style choice? > > Thanks, > Richard > ___ > 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: 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 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 Haskell in GHCJS, and I'm not sure if a week is enough > >> to test the changes. Also the recent removal of boot file merging > >> reintroduces a problem with that I'm not sure can be fixed without adding a > >> new hook. > >> > > Simon, what do you think about this? > > > > I'm a bit worried that this patch is quite late and breaks users like > > Luite. Nevertheless, I am willing to hear arguments for merging. > > It doesn't have to go in, but I think it would be nice. I'd like to > have it out for at least one major release in a disabled-by-default > state so that we can experiment with it. But as far as my particular > goals for this feature are concerned, I'll backport the patch to 7.10 > and use it in our local GHC build at Facebook regardless. > > Luite - the hooks you use are still intact, so I don't think you have to > do any major restructuring in GHCJS until you're ready. What I've > implemented will almost certainly need work to be usable or shareable > with GHCJS, and it's not clear to me exactly what the changes will look > like, but for the time being I thought the changes should not impact > GHCJS's implementation of TH & GHCi. I could be wrong though, if so > please let me know how it breaks you. > > Cheers, > Simon > > >> What's the policy on adding hooks or GHC API tweaks after the freeze? > >> > > We'll need to work that out when we get to that point. It largely > > depends upon how confined and "safe" a change appears to be. That being > > said, given how much other churn has happened for this release, I don't > > think we want to be sloppy with merge discipline this time around. > > > > Austin, what do you think? > > > > Cheers, > > > > - Ben > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
