September 2015 - ghc-devs

HEADS UP (devs, users): 8.0.1 Roadmap
by Austin Seipp 14 Sep '15

14 Sep '15

Hi *, I've returned from vacation, and last week Simon, Simon and I met up again after a long break, and talked a bit about the upcoming release. The good news is that it is going to be an exciting one! The flip side is, there's a lot of work to be done! The current plan we'd roughly like to follow is... - November: Fork the new `ghc-8.0` STABLE branch - At this point, `master` development will probably slow as we fix bugs. - This gives us 2 months or so until branch, from Today. - This is nice as the branch is close to the first RC. - December: First release candidate - Mid/late February: Final release. Here's our current feature roadmap (in basically the same place as all our previous pages): https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1 As time goes on, this page will be updated to reflect Reality™ and track it as closely as possible. So keep an eye on it! It's got the roadmap (near top) and large bug list (bottom). Now, there are some things we need, so depending on who you are, please... - *Users*: please look over the bug list! If there's a bug you need fixed that isn't there, set it to the 8.0.1 milestone (updated in Trac). If this bug is critical to you, please let us know! You can bump the priority (if we disagree, or it's workaround-able, it might get bumped down). We just need a way to see what you need, so please let us know somehow! As a reminder, our regular policy is this: if a bug is NOT marked highest or high priority, it is essentially 100% the case we will not look at it. So please make sure this is accurate. Or if you can, write a patch yourself! - *Developers*: double check the roadmap list, _and if you're responsible for something, make sure it is accurate!_ There are some great things planned to land in HEAD, but we'll have to work for it. Onward! - A better LLVM backend for Tier-1 platforms - Types are kinds and kind equality - Overloaded record fields! - Enhancements to DWARF debugging - ApplicativeDo - ... and many more... Thanks everyone! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Proposal: Include GHC version target in libraries' description
by Alexander Berntsen 14 Sep '15

14 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Problem: A frequent usecase for especially base is browsing the haddocks online on hackage (I do this myself sometimes). A frequent associated pain with this is remembering which base version corresponds to which GHC version (I feel this myself sometimes). Current solution: Consult the boot library version chart[0]. An additional step -- where there needn't be one -- may annoy the user. Furthermore, if they don't know about the chart then they're essentially lost; which usually leads to them consulting another user - -- and now we've wasted a little time for *two* of our users for no real good reason. I conjecture that this happens quite often. Which means our culmination of GHC-related time waste eventually adds up quite a bit, detracting from the overall experience. Proposed improvement: Add "[library]-[library version] is bundled with ghc-[GHC version]." in the description string of [library].cabal. This immediately clears up the confusion when looking at [library]'s hackage page. [0] <https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries/VersionHisto ry> - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVwezFAAoJENQqWdRUGk8B8jEQAMuAYjn25VB/aG5VWr8IdPoZ OSoUu+26XdJhmbOcYzHWje7gUs8FSfqxHyflasiO22uWOHHO3kfyzwOEZX0Nqc0b WboMRuNZ5dEPGAGFqxi/DWzPoaQ9shA+EUmCl8r2Qn9W7ZximaP3b1ORO0UvvgBo YK3T0f4TCoYKOYS2Txl5gjO3FKK6STdNxcELs3p6g0+paf5crEf3hcw2WZCcsdSc 0yU3dl5iFin4ofaByDmx7tj1ACYn7MusEH4zF+jjGYb4XbIV+WCy78Nsmlqt3AF9 P++HD4DMmh+rXW9tkqAbTgxn3LAgrkB0F3vYAEfiH4xFmWlQyzANtjILN6WYDOt0 5Gnpz/Meg6aGJY0U5y/XAPxzpar7oc/HPbdjS747iOTLj4dsOHeswmw++goG8ugw j/Yq00T17/3RJlZ03OdaRyl+HrXiNCq0J48LUUJu9jY9LCjr57hKZa3fFFM++fIU UaIMllxCiOdGDaTJCCZ/HEvZBtvxaeWWEc/Zi2XrtMI4PcAS/QACxlJJsHfnb/1B mCi5fIWjzX0UPo6YeRI2MeUlasKp8fLPm8AGKHQJGx2XHNHToNFR5X75VpCWWlp3 oboVm1qN46qpwnkrxWrIvlK40fLjmiZZMb0HS4cm+4ofNFc+CQMBqQ5fZxrwAO7e CTzw91s+6tbcp43Y+lgI =rmBv -----END PGP SIGNATURE-----

1 2

Deriving Contravariant and Profunctor
by David Feuer 11 Sep '15

11 Sep '15

Would it be possible to add mechanisms to derive Contravariant and Profunctor instances? As with Functor, each algebraic datatype can only have one sensible instance of each of these. David Feuer

2 3

RE: D1182: Implement improved error messages for ambiguous type variables (#10733)
by Simon Peyton Jones 11 Sep '15

11 Sep '15

Edward | Jan's injective type families commit is causing tcfail220 to fail, but | that's unrelated to this ticket. This is true. I told Jan to commit anyway because tcfail220 is a "hsig" test, and a) I know that hsigs are in flux (although I am not clear about how) b) I don't understand them enough to fix. So I hope it's ok to have broken this. Jan and I can certainly help when you want to fix it. Meanwhile would you mark it as expect-broken. (Although I am not sure that it's worth opening a fresh ticket for it.) thanks Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 03 September 2015 07:11 | To: Simon Peyton Jones | Subject: [Differential] [Commented On] D1182: Implement improved error | messages for ambiguous type variables (#10733) | | KaneTW added a comment. | | Jan's injective type families commit is causing tcfail220 to fail, but | that's unrelated to this ticket. | | | REPOSITORY | rGHC Glasgow Haskell Compiler | | REVISION DETAIL | https://phabricator.haskell.org/D1182 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: KaneTW, simonpj, bgamari, austin | Cc: goldfire, simonpj, thomie

4 3

Re: Shared data type for extension flags
by malcolm.wallace 10 Sep '15

10 Sep '15

"ghc-types" sounds like a package for fancy type hackery. I would never think to find language extension flags in such a place. How about "ghc-package-db", or "ghc-language-extensions"? Regards, Malcolm On 10 Sep, 2015,at 03:30 AM, "Edward Z. Yang" <ezyang(a)mit.edu> wrote: I don't think it makes very much sense to reuse bin-package-db; at least, not without renaming it at the very least (who'd expect a list of language extension flags to live in a binary package database?) We could name it something like 'ghc-types'? Edward Excerpts from Simon Peyton Jones's message of 2015-09-08 05:35:00 -0700: Yes, we’d have to broaden the description of the package. I defer to Edward Yang and Duncan Coutts who have a clearer idea of the architecture in this area. Simon From: Michael Smith [mailto:michael@diglumi.com] Sent: 02 September 2015 17:27 To: Simon Peyton Jones; Matthew Pickering Cc: GHC developers Subject: Re: Shared data type for extension flags The package description for that is "The GHC compiler's view of the GHC package database format", and this doesn't really have to do with the package database format. Would it be okay to put this in there anyway? On Wed, Sep 2, 2015, 07:33 Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: we already have such a shared library, I think: bin-package-db. would that do? Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org<mailto:ghc-devs-bounces@haskell.org>] On Behalf Of Michael Smith Sent: 02 September 2015 09:21 To: Matthew Pickering Cc: GHC developers Subject: Re: Shared data type for extension flags That sounds like a good approach. Are there other things that would go nicely in a shared package like this, in addition to the extension data type? On Wed, Sep 2, 2015 at 1:00 AM, Matthew Pickering <matthewtpickering(a)gmail.com<mailto:matthewtpickering@gmail.com>> wrote: Surely the easiest way here (including for other tooling - ie haskell-src-exts) is to create a package which just provides this enumeration. GHC, cabal, th, haskell-src-exts and so on then all depend on this package rather than creating their own enumeration. On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith <michael(a)diglumi.com<mailto:michael@diglumi.com>> wrote: > #10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the > capababilty > to Template Haskell to detect which language extensions enabled. > Unfortunately, > since template-haskell can't depend on ghc (as ghc depends on > template-haskell), > it can't simply re-export the ExtensionFlag type from DynFlags to the user. > > There is a second data type encoding the list of possible language > extensions in > the Cabal package, in Language.Haskell.Extension [3]. But template-haskell > doesn't already depend on Cabal, and doing so seems like it would cause > difficulties, as the two packages can be upgraded separately. > > So adding this new feature to Template Haskell requires introducing a > *third* > data type for language extensions. It also requires enumerating this full > list > in two more places, to convert back and forth between the TH Extension data > type > and GHC's internal ExtensionFlag data type. > > Is there another way here? Can there be one single shared data type for this > somehow? > > [1] https://ghc.haskell.org/trac/ghc/ticket/10820 > [2] https://phabricator.haskell.org/D1200 > [3] > https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Ex… > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

3 2

more releases
by Richard Eisenberg 10 Sep '15

10 Sep '15

Hi devs, An interesting topic came up over dinner tonight: what if GHC made more releases? As an extreme example, we could release a new point version every time a bug fix gets merged to the stable branch. This may be a terrible idea. But what's stopping us from doing so? The biggest objection I can see is that we would want to make sure that users' code would work with the new version. Could the Stackage crew help us with this? If they run their nightly build with a release candidate and diff against the prior results, we would get a pretty accurate sense of whether the bugfix is good. If this test succeeds, why not release? Would it be hard to automate the packaging/posting process? The advantage to more releases is that it gets bugfixes in more hands sooner. What are the disadvantages? Richard PS: I'm not 100% sold on this idea. But I thought it was interesting enough to raise a broader discussion.

9 12

Shared data type for extension flags
by Edward Z. Yang 09 Sep '15

09 Sep '15

I don't think it makes very much sense to reuse bin-package-db; at least, not without renaming it at the very least (who'd expect a list of language extension flags to live in a binary package database?) We could name it something like 'ghc-types'? Edward Excerpts from Simon Peyton Jones's message of 2015-09-08 05:35:00 -0700: > Yes, we’d have to broaden the description of the package. I defer to Edward Yang and Duncan Coutts who have a clearer idea of the architecture in this area. > > Simon > > From: Michael Smith [mailto:michael@diglumi.com] > Sent: 02 September 2015 17:27 > To: Simon Peyton Jones; Matthew Pickering > Cc: GHC developers > Subject: Re: Shared data type for extension flags > > > The package description for that is "The GHC compiler's view of the GHC package database format", and this doesn't really have to do with the package database format. Would it be okay to put this in there anyway? > > On Wed, Sep 2, 2015, 07:33 Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: > we already have such a shared library, I think: bin-package-db. would that do? > > Simon > > From: ghc-devs [mailto:ghc-devs-bounces@haskell.org<mailto:ghc-devs-bounces@haskell.org>] On Behalf Of Michael Smith > Sent: 02 September 2015 09:21 > To: Matthew Pickering > Cc: GHC developers > Subject: Re: Shared data type for extension flags > > That sounds like a good approach. Are there other things that would go nicely > in a shared package like this, in addition to the extension data type? > > On Wed, Sep 2, 2015 at 1:00 AM, Matthew Pickering <matthewtpickering(a)gmail.com<mailto:matthewtpickering@gmail.com>> wrote: > Surely the easiest way here (including for other tooling - ie > haskell-src-exts) is to create a package which just provides this > enumeration. GHC, cabal, th, haskell-src-exts and so on then all > depend on this package rather than creating their own enumeration. > > On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith <michael(a)diglumi.com<mailto:michael@diglumi.com>> wrote: > > #10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the > > capababilty > > to Template Haskell to detect which language extensions enabled. > > Unfortunately, > > since template-haskell can't depend on ghc (as ghc depends on > > template-haskell), > > it can't simply re-export the ExtensionFlag type from DynFlags to the user. > > > > There is a second data type encoding the list of possible language > > extensions in > > the Cabal package, in Language.Haskell.Extension [3]. But template-haskell > > doesn't already depend on Cabal, and doing so seems like it would cause > > difficulties, as the two packages can be upgraded separately. > > > > So adding this new feature to Template Haskell requires introducing a > > *third* > > data type for language extensions. It also requires enumerating this full > > list > > in two more places, to convert back and forth between the TH Extension data > > type > > and GHC's internal ExtensionFlag data type. > > > > Is there another way here? Can there be one single shared data type for this > > somehow? > > > > [1] https://ghc.haskell.org/trac/ghc/ticket/10820 > > [2] https://phabricator.haskell.org/D1200 > > [3] > > https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Ex… > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >

1 0

Proposal: Automatic derivation of Lift
by Ryan Scott 09 Sep '15

09 Sep '15

There is a Lift typeclass defined in template-haskell [1] which, when a data type is an instance, permits it to be directly used in a TH quotation, like so data Example = Example instance Lift Example where lift Example = conE (mkNameG_d "<package-name>" "<module-name>" "Example") e :: Example e = [| Example |] Making Lift instances for most data types is straightforward and mechanical, so the proposal is to allow automatic derivation of Lift via a -XDeriveLift extension: data Example = Example deriving Lift This is actually a pretty a pretty old proposal [2], dating back to 2007. I wanted to have this feature for my needs, so I submitted a proof-of-concept at the GHC Trac issue page [3]. The question now is: do we really want to bake this feature into GHC? Since not many people opined on the Trac page, I wanted to submit this here for wider visibility and to have a discussion. Here are some arguments I have heard against this feature (please tell me if I am misrepresenting your opinion): * We already have a th-lift package [4] on Hackage which allows derivation of Lift via Template Haskell functions. In addition, if you're using Lift, chances are you're also using the -XTemplateHaskell extension in the first place, so th-lift should be suitable. * The same functionality could be added via GHC generics (as of GHC 7.12/8.0, which adds the ability to reify a datatype's package name [5]), if -XTemplateHaskell can't be used. * Adding another -XDerive- extension places a burden on GHC devs to maintain it in the future in response to further Template Haskell changes. Here are my (opinionated) responses to each of these: * th-lift isn't as fully-featured as a -XDerive- extension at the moment, since it can't do sophisticated type inference [6] or derive for data families. This is something that could be addressed with a patch to th-lift, though. * GHC generics wouldn't be enough to handle unlifted types like Int#, Char#, or Double# (which other -XDerive- extensions do). * This is a subjective measurement, but in terms of the amount of code I had to add, -XDeriveLift was substantially simpler than other -XDerive extensions, because there are fewer weird corner cases. Plus, I'd volunteer to maintain it :) Simon PJ wanted to know if other Template Haskell programmers would find -XDeriveLift useful. Would you be able to use it? Would you like to see a solution other than putting it into GHC? I'd love to hear feedback so we can bring some closure to this 8-year-old feature request. Ryan S. ----- [1] http://hackage.haskell.org/package/template-haskell-2.10.0.0/docs/Language-… [2] https://mail.haskell.org/pipermail/template-haskell/2007-October/000635.html [3] https://ghc.haskell.org/trac/ghc/ticket/1830 [4] http://hackage.haskell.org/package/th-lift [5] https://ghc.haskell.org/trac/ghc/ticket/10030 [6] https://ghc.haskell.org/trac/ghc/ticket/1830#comment:11

6 7

the platform has outgrown Travis-CI
by Mark Lentczner 09 Sep '15

09 Sep '15

I finally figured out what was wrong with the Travis CI build for Haskell Platform, and got it all working w/hvr's .debs of GHC (for the boot compiler)... and ran smack into this: Your test run exceeded 50 minutes. SO... I'd like to find another CI solution. Is phabricator.haskell.org an option? Can we / should we create a project there? - Mark

5 4

RFC: Unpacking sum types
by Johan Tibell 09 Sep '15

09 Sep '15

I have a draft design for unpacking sum types that I'd like some feedback on. In particular feedback both on: * the writing and clarity of the proposal and * the proposal itself. https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes -- Johan

9 22