- ghc-devs - Haskell.org

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 10 Sep '15

10 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

ArrayArrays
by Edward Kmett 08 Sep '15

08 Sep '15

Would it be possible to add unsafe primops to add Array# and SmallArray# entries to an ArrayArray#? The fact that the ArrayArray# entries are all directly unlifted avoiding a level of indirection for the containing structure is amazing, but I can only currently use it if my leaf level data can be 100% unboxed and distributed among ByteArray#s. It'd be nice to be able to have the ability to put SmallArray# a stuff down at the leaves to hold lifted contents. I accept fully that if I name the wrong type when I go to access one of the fields it'll lie to me, but I suppose it'd do that if i tried to use one of the members that held a nested ArrayArray# as a ByteArray# anyways, so it isn't like there is a safety story preventing this. I've been hunting for ways to try to kill the indirection problems I get with Haskell and mutable structures, and I could shoehorn a number of them into ArrayArrays if this worked. Right now I'm stuck paying for 2 or 3 levels of unnecessary indirection compared to c/java and this could reduce that pain to just 1 level of unnecessary indirection. -Edward

9 46

Shared data type for extension flags
by Michael Smith 08 Sep '15

08 Sep '15

#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…

6 9

Cannot have GHC in ARMv6 architecture
by jmcf125＠openmailbox.org 07 Sep '15

07 Sep '15

Hi, I have tried to have GHC in my Raspberry Pi, got stuck in the issue 7754 (https://ghc.haskell.org/trac/ghc/ticket/7754) since I didn't know where to pass options to terminfo's configure file, although I did copy the headers from my Raspberry Pi. I've been using HUGS ever since, as Arch Linux doesn't have GHC for ARMv6, and deb2targz would not work. I'm aware I have a phase 0 compiler installed, need to build a phase 1 compiler, and use that to cross-compile GHC itself (I wasn't the 1st time I tried, couldn't find as much information as now). I've read the following pages: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/RaspberryPi https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation along with quite a few bug reports, and questions on Stack Overflow that seemed related but really aren't, or that are already exposed in the tickets mentioned below. Below, /home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/include-curses and /home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/lib-curses are directories to which I copied any headers and libraries, respectively, from my Raspberry Pi. I'm not sure which libraries I am supposed to point configure at. These are the headers-libraries combinations I tried: $ ./configure --target=arm-linux-gnueabihf --with-curses-includes=/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/include-curses --with-curses-libraries=/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/lib-curses && make -j5 (...) checking for unistd.h... yes checking ncurses.h usability... no checking ncurses.h presence... no checking for ncurses.h... no checking curses.h usability... no checking curses.h presence... no checking for curses.h... no configure: error: in `/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo': configure: error: curses headers could not be found, so this package cannot be built See `config.log' for more details libraries/terminfo/ghc.mk:4: recipe for target 'libraries/terminfo/dist-install/package-data.mk' failed make[1]: *** [libraries/terminfo/dist-install/package-data.mk] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 (https://ghc.haskell.org/trac/ghc/ticket/7754) $ ./configure --target=arm-linux-gnueabihf --with-curses-includes=/usr/include --with-curses-libraries=/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/lib-curses && make -j5 (...) checking for unistd.h... yes checking ncurses.h usability... yes checking ncurses.h presence... yes checking for ncurses.h... yes checking for setupterm in -ltinfo... no checking for setupterm in -lncursesw... no checking for setupterm in -lncurses... no checking for setupterm in -lcurses... no configure: error: in `/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo': configure: error: curses library not found, so this package cannot be built See `config.log' for more details libraries/terminfo/ghc.mk:4: recipe for target 'libraries/terminfo/dist-install/package-data.mk' failed make[1]: *** [libraries/terminfo/dist-install/package-data.mk] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 (https://ghc.haskell.org/trac/ghc/ticket/7281) $ ./configure --target=arm-linux-gnueabihf --with-curses-includes=/usr/include --with-curses-libraries=/usr/lib && make -j5 <OR> $ ./configure --target=arm-linux-gnueabihf --with-curses-includes=/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo/include-curses --with-curses-libraries=/usr/lib && make -j5 (...) Configuring terminfo-0.4.0.1... configure: WARNING: unrecognized options: --with-compiler, --with-gcc checking for arm-unknown-linux-gnueabihf-gcc... /home/jmcf125/ghc-raspberry-pi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc checking whether the C compiler works... no configure: error: in `/home/jmcf125/ghc-raspberry-pi/ghc/libraries/terminfo': configure: error: C compiler cannot create executables See `config.log' for more details libraries/terminfo/ghc.mk:4: recipe for target 'libraries/terminfo/dist-install/package-data.mk' failed make[1]: *** [libraries/terminfo/dist-install/package-data.mk] Error 77 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 Concerning the last 2, it'd be odd if they worked, how could, say, the GCC cross-compiler for ARM use x86_64 libraries? I tried them anyway, since the 1st 2 errors didn't seem to make sense... Also, options --includedir and --oldincludedir seem to have no effect (always get issue 7754), and it doesn't matter if I build registarised or not, the results are the same (registarised, I'm using LLVM 3.6.2-3). I'm sorry if I'm wasting your time with what to you might seem such a simple thing, and not real development on GHC, but I don't know where else to turn to. I'm still learning Haskell, and have never had to compile compilers before. Thank you in advance, João Miguel

2 1