January 2016 - ghc-devs

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

Options -Wmissed-specialisations, -Wall-missed-specialisations and -Werror
by Andrés Sicard-Ramírez 23 Jan '16

23 Jan '16

Dear all, In GHC 8 RC 1, the `-Wmissed-specialisations` and `-Wall-missed-specialisations` options generate a warning instead of an error when using `-Werror`. Is it the expected behaviour? Best, -- Andrés

2 1

Fwd: Fwd: Host-Oriented Template Haskell
by Ericson, John 23 Jan '16

23 Jan '16

Oops, Sent just to Edward by mistake. ---- That all sounds good to me---I think what I was thinking all along in fact, unless I am still missing some nuance :). My idea of using a multi-target compiler was to avoid needing stage0 to be the same version as stage1 (or adding a new stage, stage1 as in your alternative). The cross compiler is multi-target so it doesn't need to link another compiler to load plugins / run "host-oriented Template Haskell". I mentioned the usecase of trying to build a stage2 which needs plugins / Host-Oriented Template Haskell, but it could well apply to building anything else with the need for those to things (and not normal TH, which cannot be built with a cross compiler) In diagrams, rather than: > stage0 (version foo, platform-x -> platform-x) > ==> stage1 (version foo, platform-x -> platform-y) > ==> some program (with plugins, with host-oriented TH, without normal TH) or > stage0 (version bar, platform-x -> platform-x) > ==> stage1 (version foo, platform-x -> platform-x) -> > ==> stage2 (version foo, platform-x -> platform-y) -> > ==> some program (with plugins, with host-oriented TH, without normal TH) do just > stage0 (version bar, platform-x -> platform-x) > ==> stage1 (version foo, platform-x -> {platform-x, platform-y}) > ==> some program (with plugins, with host-oriented TH, without normal TH) Now it may be that building such a multi-target compiler today is just as arduous as making sure one has a native compiler of the same version before building the cross compiler, so my idea is of no practical value. But if so, I hope in the long term that could be fixed. John On Wed, Jan 20, 2016 at 8:37 PM, Edward Z. Yang <ezyang(a)mit.edu> wrote: > Hello John, > > Almost! > > As you point out, if you just want a cross-compiler, you don't > need to build stage2. The real problem is that we want stage0 > to be *the same version* as stage1, so that stage0 has the correct > API in order to load stage0 libraries which are going to be used > for TH, plugins, etc. (Alternately, build a non-cross-compiler > stage1, and then a cross-compiler stage2--NOT a cross compiled > stage 2.) > > Edward > > Excerpts from Ericson, John's message of 2016-01-19 16:13:24 -0800: >> From #11378: >> >> > Can we actually link against the old version of ghc? Yes we can! All we need is >> > (1) for it to have been built with a different IPID, and >> > (2) to use module renaming to rename the relevant modules to a different >> > module name, so that we can import them without a conflict. >> >> >> If I understand this, you are saying stage1 links stage0 (the normal, >> non-cross-compiler used to build stage1), to build stage2? I agree >> that should work, but if stage1 is multi-target isn't that level of >> complexity not even needed? I'm not too familiar with GHC or its build >> system, but a multi-target compiler that doesn't support normal TH >> doesn't seem that hard to build in principle. >> >> John >> >> On Tue, Jan 19, 2016 at 3:59 PM, Ericson, John <john_ericson(a)brown.edu> wrote: >> > Ah thanks for the link. Template Haskell with only {-# TH-ONLY #-} >> > imports is precisely equivalent to what I propose. I find a clean >> > separation with that and normal TH useful, however, precisely so the >> > stage2 compiler's source can include such a thing. >> > >> > On Tue, Jan 19, 2016 at 3:20 PM, Edward Z. Yang <ezyang(a)mit.edu> wrote: >> >> Hello John >> >> >> >> You may find this implementation ticket of interest: >> >> https://ghc.haskell.org/trac/ghc/ticket/11378 >> >> >> >> Edward >> >> >> >> Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800: >> >>> Cross-posting this as was suggested on the Haskell-Cafe list. While I >> >>> envision this as normal feature that anyone can use, in practice its >> >>> biggest consumers would be GHC devs. >> >>> >> >>> John >> >>> >> >>> ---------- Forwarded message ---------- >> >>> From: Ericson, John <john_ericson(a)brown.edu> >> >>> Date: Tue, Jan 19, 2016 at 1:17 PM >> >>> Subject: Host-Oriented Template Haskell >> >>> To: Haskell-Cafe <haskell-cafe(a)haskell.org> >> >>> >> >>> >> >>> As is well known, TH and cross-compiling do not get along. There are >> >>> various proposals on how to make this interaction less annoying, and I >> >>> am not against them. But as I see it, the problem is largely inherent >> >>> to the design of TH itself: since values can (usually) be lifted from >> >>> compile-time to run-time, and normal definitions from upstream modules >> >>> to downstream modules' TH, TH and normal code must "live in the same >> >>> world". >> >>> >> >>> Now this restriction in turn bequeaths TH with much expressive power, >> >>> and I wouldn't advocate getting rid of it. But many tasks do not need >> >>> it, and in some cases, say in bootstrapping compilers[1] themselves, >> >>> it is impossible to use TH because of it, even were all the current >> >>> proposals implemented. >> >>> >> >>> For these reason, I propose a new TH variant which has much harsher >> >>> phase separation. Normal definitions from upstream modules can not be >> >>> used, lifting values is either not permitted or is allowed to fail >> >>> (because of missing/incompatible definitions), and IO is defined to >> >>> match the behavior of the host, not target, platform (in the cross >> >>> compiling case). The only interaction between the two phases is that >> >>> quoted syntax is resolved against the the run-time phase's definitions >> >>> (just like today). >> >>> >> >>> Some of you may find this a shoddy substitute for defining a subset of >> >>> Haskell which behaves identically on all platforms, and optionally >> >>> constraining TH to it. But the big feature that my proposal offers and >> >>> that one doesn't is to be able to independently specify compile-time >> >>> dependencies for the host-oriented TH---this is analogous to the >> >>> newish `Setup.hs` dependencies. That in turns leads to what I think is >> >>> the "killer app" for Host-Oriented TH: exposing the various >> >>> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries, >> >>> and side-stepping any need for "executable dependencies" in Cabal. >> >>> Note also that at least hsc2hs additionally requires host-IO---there >> >>> may not even exist a C compiler on the target platform at all. >> >>> >> >>> Finally, forgive me if this has been brought up before. I've been >> >>> thinking about this a while, and did a final pass over the GHC wiki to >> >>> make sure it wasn't already proposed, but I could have missed >> >>> something (this is also my first post to the list). >> >>> >> >>> John >> >>> >> >>> [1]: https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Intern… >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs(a)haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

3 4

Phabricator upgrade - CI will be down for a short time
by Austin Seipp 21 Jan '16

21 Jan '16

Hi *, TL;DR Phabricator will go down for about 5 minutes later today, but the CI will be off for a while longer. I wanted to alert everyone: I'll be upgrading Phabricator shortly this morning, after doing a bunch of testing to make sure our upgrade will go smoothly. Luckily, it will go quite smoothly. The upgrade on the database backup I performed went without a hitch, and everything still seems to work quite well. You shouldn't really notice a huge difference in day-to-day usage... However, it will require redoing some pieces of the CI system, so when I do the upgrade, _Harbormaster won't work for a short time_. That means your patches won't get built - do not be alarmed by this. I tested this before, but we'll have to do some other changes to make it happen 'for real' this time (including some CDN fiddling). Ben also recently rewrote the terrible build script I originally wrote, so I'd like to deploy it instead if possible. Thomas has also rightfully prodded me about some of the current CI complaints, so hopefully these can be sorted out too. This upgrade has been long in the tooth, but luckily you shouldn't notice much beyond a minor hitch here, and CI being gone for a little while. Hopefully it should be done by the end of the day. In the mean time, I'll give Ben access to the newer (20 core) buildbot, so he'll be able to validate your changes quite quickly for integration. I'll reply to this email with updates. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 3