- ghc-devs - Haskell.org

Adding a "release" setting in build.mk.sample (and some other build system questions)
by Ömer Sinan Ağacan 29 Jan '16

29 Jan '16

I'm trying to figure out how to generate a release build. I thought it should be "perf" setting, but then I realized ghc-stage1 is called with -O (instead of -O2) when building stage2 with perf setting. So either perf is not the release setting, or I need stage3 which is probably compiled with stage2 using -O2? In any case, it'd be great to document this process of generating a release build in build.mk.sample. If it's "perf" setting, then maybe we can rename it to "release" or at least add a comment saying that that's the release build and you should wait until stage3 is done. Another thing that always confuses me is these settings: SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O GhcStage2HcOpts = -O2 GhcLibHcOpts = -O2 As far as I can see, there's no documentation about these in the source tree. I figured that `GhcStage1HcOpts` is passed to system GHC when compiling stage1, and `GhcStage2Hcopts` is passed to ghc-stage1 when compiling stage 2. The lib one is obvious, and it's passed to stage 1 as libs are built using stage 1. But I still don't understand how is `SRC_HC_OPTS` is used, and what is used when building stage 3.

2 1

Unexpected lack of change in ghcspeed results
by Reid Barton 28 Jan '16

28 Jan '16

Hi Joachim, I was interested to see what effect the recent commit "Restore original alignment for info tables" (0dc7b36c) would have on performance. However, when I look at http://ghcspeed-nomeata.rhcloud.com/changes/?rev=0dc7b36c3c261b3eccf8460581…, I don't see the expected binary size increase (about 1%) that I got in local testing. Instead, the size increase appears to be attached to commit 0d92d9cb6d65fd00f9910c3f6f85bc6c68f5543b. I notice that these two commits, along with three others, were committed at exactly the same time (Wed Jan 27 11:32:15 2016 +0100), presumably in a rebase. Could this be confusing ghcspeed? Regards, Reid Barton

2 4

GHC 8.0.1 plans
by Ben Gamari 27 Jan '16

27 Jan '16

tl;dr: The march towards 8.0.1 continues. Release candidate 2 will likely be cut late next week. If you have a ticket which you'd like to see addressed but suspect we aren't working on then please say so. Hello again GHC-ers, As you likely know, we are currently in the stabilization period of GHC's 8.0.1 release. Release candidate 1 has been out for nearly two weeks now and issues have been steadily trickling in. The problems we've heard about thusfar have largely fallen into a few broad categories, * OS X linker issues due to botched preparation of the first binary distribution (#11423) * pattern match checker performance. These we largely knew about prior to the release, although it has been surprising to see how easily one can wander into the new checker's performance abyss. (#11374, #11276, #11163, #11302, #11303, #11195) * Regressions due to visible type applications (#11329, #11458) * Issues uncovered by generalizations allowed under TypeInType (#11429, #11334, #11473, #11405, #11407, #11399) * Trouble caused by new warnings (#11370, #11316, #11474) Since the release, there has been significant progress on many of these fronts: * George Karachalias has been hard at work further improving the pattern checker. The result should have far more predictable performance characteristics at less cost in reasoning power. * Simon Peyton Jones has been squashing bugs at a furious rate, including a variety of long-standing issues (#11248, #11330 and many others) * Tamar Christina has added support for remote GHCi on Windows and resolved a long-standing linking issue (#11223, #11100) * A variety of limitations in our implementation of Typeable have been fixed (#11120) although there is still more to be done (#11334). * InjectiveTypeFamilies has been renamed to TypeFamiliesDependencies * Custom type errors are now more robust (#11391) * We now have a more conservative default warning set, as well as better mechanisms for managing warning changes in the future. (#11429, #11370) * A wide variety of miscellaneous bug-fixes have also been merged. Given how much progress has been made, we approaching the point where we can begin planning the next candidate. At this point the plan is to wait until we have landed George's pattern checker rework, as this has been one of the more visible issues in practice. This may be merged as early as the latter half of next week. If this happens then we hope to have the next release candidate out late next week. In the interim we will continue to work on paring down the bug list, focusing on the highest priority tickets listed on the 8.0.1 status page. In particular, those with owners are most likely to be dealt with soon. If you see a ticket which you would like to see addressed in 8.0.1 but is unowned or lower than "highest" priority, please bring this to our attention. Given the large amount of churn still being felt in the `ghc-8.0` branch (with over 150 comments in the two weeks since -rc1) and the size of some of the patches that have yet to land, it's unclear whether two release candidates will be sufficient to ensure the stability of the branch. Consequently, unless -rc2 yields a particularly small number of new tickets it's likely that it will be followed by a third candidate before the release. As always, let us know if you have any questions or concerns about the release process. Thanks to everyone who has contributed to -rc1! Cheers, - Ben

2 2

GHC release candidate
by Simon Peyton Jones 27 Jan '16

27 Jan '16

George, Richard, Geoff We’d like to get a new release candidate for GHC out on Friday 5th Feb. Does that give you enough post-POPL time to get done? · George: The pattern match performance issues · Richard: the ReturnTv stuff (branch wip/exp-types) · Richard: #11471 (levity) · Richard: documentation for TypeInType · Geoff: #11487 · Simon PJ: #11339 Richard, also if you look at https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 you can see “highest” priority tickets with you as owner, that are to do with TypeInType and TypeApplications. Thanks Simon

3 4

RE: [ANNOUNCE] Shaking up GHC
by Andrey Mokhov 26 Jan '16

26 Jan '16

Thanks David! > Are there any plans as to how to include it in the GHC tree? Does it > ship with all the libraries required to build the build system, will we > have a mini-build system to bootstrap it? If I recall correctly, we rely > on Cabal sandboxes on Linux/OSX and global Cabal library > installations on Windows in order to run it. The simplest way is to add the 'shake-build' folder to the GHC tree and ask first adopters of the new build system to globally install the dependencies (ansi-terminal, mtl, shake, QuickCheck). Then 'build.sh' and 'build.bat' scripts should work. I am open to suggestions on how to make this more convenient and robust. I've never used anything more advanced than a global cabal installation, so I'd appreciate input from more experienced users. Could you create a ticket on github suggesting possible approaches? I'm afraid our discussion may get lost in ghc-devs mailing list. Many thanks! Andrey > From: David Luposchainsky <dluposchainsky(a)googlemail.com> > To: ghc-devs(a)haskell.org > Subject: Re: [ANNOUNCE] Shaking up GHC > Message-ID: <56A27EB1.1080701(a)gmail.com> > Content-Type: text/plain; charset=windows-1252 > > Great work Andrey! > > I'm actually (pleasantly) surprised this is becoming part of the GHC > tree so soon > . > > Are there any plans as to how to include it in the GHC tree? Does it > ship with > all the libraries required to build the build system, will we have a > mini-build > system to bootstrap it? If I recall correctly, we rely on Cabal > sandboxes on > Linux/OSX and global Cabal library installations on Windows in order to > run it. > > Greetings, > David

10 17

Substitutions
by Simon Peyton Jones 26 Jan '16

26 Jan '16

Bartosz How are you getting on with tidying up substitutions. I’ve done a bit in that direction myself: commit 1c6d70c2121fd1126fcc2458bdbcc856e19598c2 Author: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Date: Tue Jan 26 09:37:06 2016 +0000 Kill off zipTopTCvSubst in favour of zipOpenTCvSubst But there is more to do. In particular, I note that substTys is not checked – but neither is it called substTysUnchecked. It should be! That will show up a bunch more cases, I think. Another particular thing, arising from my patch, is that we can now do some renaming · zipOpenTCvSubst -> zipTvSubst (It only deals with tyvars) · zipOpenTCvSubstCoVars -> zipCvSubst (it only deals with covars) · zipOpenTCvSubstBinders -> zipTyBinderSubst (it only deals with TyBinders, not covars) I guess you’ll want to do similar things for the “mk” variants. Anyway: good for you! Let me know if you need help. Simon

2 2

Re: Type class for sanity
by David Feuer 25 Jan '16

25 Jan '16

You're correct. Please forget that name. On Jan 25, 2016 12:33 PM, "wren romano" <wren(a)community.haskell.org> wrote: > On Mon, Jan 25, 2016 at 7:34 AM, Richard Eisenberg <eir(a)cis.upenn.edu> > wrote: > > But I suggest a different name. Ground? Terminating? NormalForm? > Irreducible? ValueType? I don't love any of these, but I love Sane less. > > I'm also strongly opposed to using "sane". That name is ableist and > quite offputting to many Haskellers I know (myself included). To say > nothing of the fact that the name doesn't provide any useful > understanding of what precisely it's supposed to be categorizing. > > -- > Live well, > ~wren > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

1 0

dynamic linking and GHC 8.0.1 User's Guide
by George Colpitts 25 Jan '16

25 Jan '16

I believe that static linking will produce a faster program, at least in some situations. If so it would be good to mention this in section 8.2 of the user's guide, *Faster: producing a program that runs quicker, * I couldn't find documentation for the -dynamic-too option of GHC. If it isn't there it would be good to document. I looked in the index, and sections 6.11.5. *Options affecting code generation, *and 6.11.6. *Options affecting linking.* Is there a pdf version of the GHC 8.0.1 User's Guide? It' much easier to search in the pdf version. 8.0.1 rc1 just has an html version but perhaps there is a pdf version available on the web somewhere. I assume the final version of 8.0.1 will have a pdf version. Thanks George

2 2

Type class for sanity
by David Feuer 25 Jan '16

25 Jan '16

Since type families can be stuck, it's sometimes useful to restrict things to sane types. At present, the most convenient way I can see to do this in general is with Typeable: type family Foo x where Foo 'True = Int class Typeable (Foo x) => Bar x where blah :: proxy x -> Foo x This will prevent anyone from producing the bogus instance instance Bar 'False where blah _ = undefined Unfortunately, the Typeable constraint carries runtime overhead. One possible way around this, I think, is with a class that does just sanity checking and nothing more: class Sane (a :: k) instance Sane Int instance Sane Char instance Sane 'False instance Sane 'True instance Sane '[] instance Sane '(:) instance Sane (->) instance Sane 'Just instance Sane 'Nothing instance (Sane f, Sane x) => Sane (f x) To really do its job properly, Sane would need to have instances for all sane types and no more. An example of an insane instance of Sane would be instance Sane (a :: MyKind) which would include stuck types of kind MyKind. Would it be useful to add such an automatic-only class to GHC? David

3 5

Re: Type class for sanity
by David Feuer 25 Jan '16

25 Jan '16

See https://typesandkinds.wordpress.com/2015/09/09/what-are-type-families/ for some discussion. A type family application is stuck if it can't reduce further and has not reached a proper type. Given the aforementioned type family Foo, the application Foo 'False is stuck. It's a type of kind *, and it's uninhabited (but not as nicely uninhabited as Void--it offers no ex falso). This actually turns out to be useful for some things. GHC offers type family Any :: k where {} which is, at least, 1. A safe intermediate target for unsafeCoerce 2. An utterly unsatisfiable constraint (see the definition of Bottom in the GitHub master of the reflection package) But sometimes you want to know something's *not* a stuck type family. See the issue I filed earlier today at https://github.com/kwf/ComonadSheet/issues/6 for an example--the code tries to make a certain instance impossible to produce, but the possibility of stuckness defeats it as its currently written. On Jan 25, 2016 1:01 AM, "Jeffrey Brown" <jeffbrown.the(a)gmail.com> wrote: > "Stuck type" is proving difficult to Google. Do you recommend any > references? > > On Sun, Jan 24, 2016 at 1:24 PM, David Feuer <david.feuer(a)gmail.com> > wrote: > >> Since type families can be stuck, it's sometimes useful to restrict >> things to sane types. At present, the most convenient way I can see to >> do this in general is with Typeable: >> >> type family Foo x where >> Foo 'True = Int >> >> class Typeable (Foo x) => Bar x where >> blah :: proxy x -> Foo x >> >> This will prevent anyone from producing the bogus instance >> >> instance Bar 'False where >> blah _ = undefined >> >> Unfortunately, the Typeable constraint carries runtime overhead. One >> possible way around this, I think, is with a class that does just >> sanity checking and nothing more: >> >> class Sane (a :: k) >> instance Sane Int >> instance Sane Char >> instance Sane 'False >> instance Sane 'True >> instance Sane '[] >> instance Sane '(:) >> instance Sane (->) >> instance Sane 'Just >> instance Sane 'Nothing >> instance (Sane f, Sane x) => Sane (f x) >> >> To really do its job properly, Sane would need to have instances for >> all sane types and no more. An example of an insane instance of Sane >> would be >> >> instance Sane (a :: MyKind) >> >> which would include stuck types of kind MyKind. >> >> Would it be useful to add such an automatic-only class to GHC? >> >> David >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > > -- > Jeffrey Benjamin Brown >

1 0