- ghc-devs - Haskell.org

FYI: base version bump landing soon
by Ben Gamari 15 Dec '16

15 Dec '16

Hello fellow Haskellers, Sometime soon (likely today) I'll be landing a commit to `master` which will bump the version of the `base` library to 4.10.0.0 This will involve bumping a number of submodules as well. This will mean that testing against Hackage will typically require that you pass `--allow-newer=base` to cabal. Cheers, - Ben

1 0

Compile GHC with -prof to get a stack trace on panic
by Simon Marlow 15 Dec '16

15 Dec '16

I think this has been mentioned before but it's probably not widely known: if you compile GHC profiled (that is, enable GhcProfiled=YES in your mk/ build.mk), then every panic comes with a stack trace. Here's one I just saw: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161206 for x86_64-unknown-linux): Ix{Int}.index: Index (65536) out of range ((0,28)) CallStack (from -prof): HscTypes.bin_fixities (compiler/main/HscTypes.hs:1050:51-56) HscMain.checkOldIface (compiler/main/HscMain.hs:(586,20)-(587,60)) HscMain.hscIncrementalFrontend (compiler/main/HscMain.hs:(556,1)-(618,81)) HscMain.hscIncrementalCompile (compiler/main/HscMain.hs:(644,1)-(699,32)) GHC.withCleanupSession (compiler/main/GHC.hs:(464,1)-(473,27)) GHC.runGhc (compiler/main/GHC.hs:(439,1)-(444,26)) GHC.defaultErrorHandler (compiler/main/GHC.hs:(379,1)-(411,7)) To get more detail in the stack trace you need to add GhcStage2HcOpts += -fprof-auto-top Or -fprof-auto, depending on how much detail you want. Cheers Simon

1 0

Explicit inequality evidence
by David Feuer 15 Dec '16

15 Dec '16

According to Ben Gamari's wiki page[1], the new Typeable is expected to offer eqTypeRep :: forall k (a :: k) (b :: k). TypeRep a -> TypeRep b -> Maybe (a :~: b) Ideally, we'd prefer to get either evidence of equality or evidence of inequality. The traditional approach is to use Dec (a :~: b), where data Dec a = Yes a | No (a -> Void). But a :~: b -> Void isn't strong enough for all purposes. In particular, if we want to use inequality to drive type family reduction, we could be in trouble. I'm wondering if we could expose inequality much as we expose equality. Under an a # b constraint, GHC would recognize a and b as unequal. Some rules: Base rules 1. f x # a -> b 2. If C is a constructor, then C # f x and C # a -> b 3. If C and D are distinct constructors, then C # D Propagation rules 1. x # y <=> (x -> z) # (y -> z) <=> (z -> x) # (z -> y) 2. x # y <=> (x z) # (y z) <=> (z x) # (z y) 3. If x # y then y # x Irreflexivity 1. x # x is unsatisfiable (this rule would be used for checking patterns). With this hypothetical machinery in place, we could get something like data a :#: b where Unequal :: a # b => Unequal (a :#: b) eqTypeRep' :: forall k (a :: k) (b :: k). TypeRep a -> TypeRep b -> Either (a :#: b) (a :~: b) Pattern matching on an Unequal constructor would reveal the inequality, allowing closed type families relying on it to reduce. Evidence structure: Whereas (:~:) has just one value, Refl, it would be possible to imagine richer evidence of inequality. If two types are unequal, then they must be unequal in some particular fashion. I conjecture that we don't actually gain much value by using rich evidence here. If the types are Typeable, then we can explore them ourselves, using eqTypeRep' recursively to locate one or more differences. If they're not, I don't think we can track the source(s) of inequality in a coherent fashion. The information we got would only be suitable for use in an error message. So one option would be to bundle up some strings describing the known mismatch, and warn the user very sternly that they shouldn't try to do anything too terribly fancy with them. [1] https://ghc.haskell.org/trac/ghc/wiki/Typeable/BenGamari

4 7

Join points!
by Simon Peyton Jones 15 Dec '16

15 Dec '16

Everyone: please take a look. Luke Very good. · I think it’s fine to work from your repo; no need to use the main repo. · One big patch is fine. The exception is late lambda-lifting which would best be done separately. · Can you identify any bits that you are less happy with? · Before long, can you put up nofib figures? Make a Trac ticket for this too. On Phab, you can have dialogue about “what does this line of code mean”. On Trac you can have longer-term strategic concerns. There isn’t a clear boundary. But Trac persists and Phab really doesn’t. We should talk about your question about floating. Simon From: Luke Maurer [mailto:maurerl@cs.uoregon.edu] Sent: 15 December 2016 10:52 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Phab diff up Okay, after some further cleanups, I've put up a Phabricator diff: https://phabricator.haskell.org/D2853 (Has some lint failures, but I figure better to put it up sooner … will fix after I get some sleep) Was going to push to a branch in the official GHC repo, too, but I don't think I have push access? Anyway, should I try and split it up into pieces? Hard to see how that would work, given how many interconnected pieces there are. I suppose if you apply the changes to Core Lint last, it might work … Also, the patch includes the stuff from the late lambda-lifting branch, which is perhaps more than we want to push at once! Certainly that much is splittable, if desired. I'm also just not as happy with that code. - Luke

1 0

Fwd: [Ann] Haskell Ecosystem Proposals
by Alan & Kim Zimmerman 15 Dec '16

15 Dec '16

I am forwarding this mail to ghc-devs and cabal-devs in case anyone missed the original which went to haskell-cafe only. Alan ---------- Forwarded message ---------- From: Alan & Kim Zimmerman <alan.zimm(a)gmail.com> Date: Sun, Dec 11, 2016 at 9:39 PM Subject: [Ann] Haskell Ecosystem Proposals To: haskell <haskell-cafe(a)haskell.org> Earlier this year Simon Peyton Jones wrote about respect [1], and said "It's worth separating two things 1. Publicly debating an issue where judgements differ 2. Using offensive or adversarial language in that debate" There is now a repository[2] for us as a community to have the first kind of discussion about issues that affect the community as a whole. The intention is that this becomes a neutral place where discussion can take place about coordinating the various services offered to the haskell community. This is partly to expose the thinking and constraints on a particular approach, so proponents of other approaches can have a better understanding of how things can evolve. The idea is that through an honest understanding of the various parts we can achieve consensus on how to improve things. If this all sounds a bit handwavy, the first concrete example of this approach is a pull request [3] discussing the management of implicit or speculative version bounds between cabal-install/hackage and stack/stackage. This has reached a point where there is a clearer understanding of the actual problem, and a viable solution must be agreed. The structure of the repository is shamelessly copied from the one for GHC proposals, so the actual process description is way off. It should probably just state that we discuss until consensus is reached if possible, but that we are always open for further discussion. It is up to all of us to make this work. Regards Alan [1] https://mail.haskell.org/pipermail/haskell/2016-September/024995.html [2] https://github.com/haskell/ecosystem-proposals [3] https://github.com/haskell/ecosystem-proposals/pull/1

1 0

Reverted f723ba2f3b6d778f903fb1de4a5af93fe65eed10
by Ben Gamari 13 Dec '16

13 Dec '16

Hi Simon, Earlier today I noticed that the testsuite started failing with f723ba2f3b6d778f903fb1de4a5af93fe65eed10 due to break024 and break011. See https://phabricator.haskell.org/harbormaster/build/16407/ (I've included the output differences below). I've reverted the patch to keep the tree buildable but obviously feel free to commit again when it validates. Cheers, - Ben --- "/tmp/ghctest-zc_e5ng4/test spaces/./ghci.debugger/scripts/break011.run/break011.stdout.normalised" 2016-12-13 01:09:56.868988119 +0000 +++ "/tmp/ghctest-zc_e5ng4/test spaces/./ghci.debugger/scripts/break011.run/break011.run.stdout.normalised" 2016-12-13 01:09:56.868988119 +0000 @@ -40,17 +40,9 @@ CallStack (from HasCallStack): error, called at Test7.hs:<line>:<column> in <package-id>:Main Stopped in <exception thrown>, <unknown> -_exception :: e = SomeException - (ErrorCallWithLocation - "foo" - "CallStack (from HasCallStack): - error, called at Test7.hs:<line>:<column> in <package-id>:Main") +_exception :: e = _ Stopped in <exception thrown>, <unknown> -_exception :: e = SomeException - (ErrorCallWithLocation - "foo" - "CallStack (from HasCallStack): - error, called at Test7.hs:<line>:<column> in <package-id>:Main") +_exception :: e = _ *** Exception: foo CallStack (from HasCallStack): error, called at Test7.hs:<line>:<column> in <package-id>:Main --- "/tmp/ghctest-zc_e5ng4/test spaces/./ghci.debugger/scripts/break024.run/break024.stdout.normalised" 2016-12-13 01:09:57.464988119 +0000 +++ "/tmp/ghctest-zc_e5ng4/test spaces/./ghci.debugger/scripts/break024.run/break024.run.stdout.normalised" 2016-12-13 01:09:57.464988119 +0000 @@ -11,8 +11,7 @@ (GHC.IO.Exception.IOError Nothing GHC.IO.Exception.UserError [] "error" Nothing Nothing) Stopped in <exception thrown>, <unknown> -_exception :: e = SomeException - (GHC.IO.Exception.IOError Nothing GHC.IO.Exception.UserError ....) +_exception :: e = _ Stopped in <exception thrown>, <unknown> _exception :: e = _ _exception = SomeException

2 1

Reason for fixing minimum bootstrap version at 2 major releases ago?
by Shea Levy 13 Dec '16

13 Dec '16

Hi all, I'm wondering, why do we require ghc to be bootstrappable with the past 2 major releases instead of just the past 1? Is it a common case that someone is compiling GHC but can't easily get the latest release? Thanks, Shea

2 1

Re: [GHC] #876: Length is not a good consumer
by George Colpitts 13 Dec '16

13 Dec '16

my apologies, sorry for the terrible bug report On Sun, Dec 11, 2016 at 11:05 AM GHC <ghc-devs(a)haskell.org> wrote: > #876: Length is not a good consumer > -------------------------------------+------------------------------------- > Reporter: ariep@… | Owner: > Type: bug | Status: new > Priority: lowest | Milestone: 7.6.2 > Component: libraries/base | Version: 6.5 > Resolution: | Keywords: length > Operating System: Linux | Architecture: > | Unknown/Multiple > Type of failure: Runtime | Test Case: > performance bug | perf/should_run/T876 > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by nomeata): > > This code, compiled with `-O, does fuse, and allocates nothing (or > constant amounts) > {{{#!hs > > module Foo where > x :: Int -> Int > x n = length [0..(10^n)::Int] > }}} > > {{{ > $ ghci -fobject-code -O Foo > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) > Ok, modules loaded: Foo. > Prelude Foo> :set +s > Prelude Foo> x 1 > 11 > (0.03 secs, 14,976,744 bytes) > Prelude Foo> x 7 > 10000001 > (0.02 secs, 0 bytes) > Prelude Foo> x 8 > 100000001 > (0.04 secs, 0 bytes) > }}} > > (almost) HEAD: > {{{ > GHCi, version 8.1.20161117: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Foo (.hs -> .o) > WARNING: file compiler/simplCore/SimplCore.hs, line 663 > Simplifier bailing out after 4 iterations [58, 14, 2, 2] > Size = {terms: 96, types: 32, coercions: 0} > Ok, modules loaded: Foo (Foo.o). > Prelude Foo> :set +s > Prelude Foo> x 1 > 11 > (0.19 secs, 94,792 bytes) > Prelude Foo> x 2 > 101 > (0.01 secs, 94,648 bytes) > Prelude Foo> x 7 > 10000001 > (0.01 secs, 98,568 bytes) > Prelude Foo> x 8 > 100000001 > (0.05 secs, 98,448 bytes) > }}} > > Testing this in with interpreted code is not sufficient, as the optimizer > does less in that case. So so far, everything seems as expected to me. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/876#comment:30> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

2 3

Please don’t break travis
by Joachim Breitner 12 Dec '16

12 Dec '16

Hi, again, Travis is failing to build master since a while. Unfortunately, only the author of commits get mailed by Travis, so I did not notice it so far. But usually, when Travis reports a build failure, this is something actionable! If in doubt, contact me. The breakage at the moment occurs only with -DDEBUG on: Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161118 for x86_64-unknown-linux): No match in record selector is_iloc Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for rn017(normal) Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161118 for x86_64-unknown-linux): No match in record selector is_iloc Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T7672(normal) And started appearing, unless I am mistaken, with From: Matthew Pickering < matthewtpickering(a)gmail.com > Date: Fri, 18 Nov 2016 16:28:30 +0000 Subject: [PATCH] Optimise whole module exports We directly build up the correct AvailInfos rather than generating lots of singleton instances and combining them with expensive calls to unionLists. There are two other small changes. * Pushed the nubAvails call into the explicit export list branch as we construct them correctly and uniquely ourselves. * fix_faminst only needs to check the first element of the export list as we maintain the (yucky) invariant that the parent is the first thing in it. Reviewers: simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: simonpj, thomie, niteria Differential Revision: https://phabricator.haskell.org/D2657 Matthew, can you verify that this is a regression introduce here? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

5 7

RE: More windows woe
by Simon Peyton Jones 10 Dec '16

10 Dec '16

Reverting didn’t work Appluying D2817 didn’t work: /c/code/HEAD$ c:/code/HEAD/inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20161209: http://www.haskell.org/ghc/ :? for help ghc-stage2.exe: unable to load package `base-4.9.0.0' ghc-stage2.exe: C:\code\HEAD\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a: unknown symbol `_unlock_file' Now it’s ‘unlock_file’. I’ll try adding that. Simon From: Phyx [mailto:lonetiger@gmail.com] Sent: 09 December 2016 23:07 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: More windows woe When fixing bootstrapping with pre 7.10.3 compilers this accidentally broke. There's a patch up to fix it https://phabricator.haskell.org/D2817 If you're on 7.10.3 or later for your bootstrapping compiler revert 6da62535469149d69ec98674db1c51dbde0efab1 and it should work again. Just waiting for a buildbot build to commit the above patch. On Fri, Dec 9, 2016 at 10:44 PM, Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> wrote: I see that anything involving ghci fails: /c/code/HEAD/inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20161209: http://www.haskell.org/ghc/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haskell…> :? for help ghc-stage2.exe: unable to load package `base-4.9.0.0' ghc-stage2.exe: C:\code\HEAD\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a: unknown symbol `_lock_file' ghc-stage2.exe: Could not on-demand load symbol '__mingw_vfprintf' ghc-stage2.exe: C:\code\HEAD\libraries\base\dist-install\build\HSbase-4.9.0.0.o: unknown symbol `__mingw_vfprintf' It’s frustrating. It used to work! Simon _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel…>

1 1