April 2016 - ghc-devs

make target doesn't include make pdf or html targets by default!
by Carter Schonwald 23 Apr '16

23 Apr '16

even though i had sphinx html and pdf flags set to YES in my mk/build.mk file! this was quite surprising. This seems to have been a change that happened sometime after the RC3 tag...

2 1

[ANNOUNCE] GHC 8.0.1 release candidate 3 available
by Ben Gamari 23 Apr '16

23 Apr '16

Hello Haskellers, The GHC team is happy to announce the availability of third release candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and binary distributions can be found at, http://downloads.haskell.org/~ghc/8.0.1-rc3/ This is the third of what will be four candidates leading up to the 8.0.1 release. As there are a number of known issues with this candidate, we expect to produce the fourth and final release candidate shortly. While we considered not releasing this candidate at all and instead skipping to rc4, we decided that it would be helpful to make it available despite its issues to increase the likelihood of catching any remaining bugs. That being said, this candidate lacks the range of binary distributions which we usually offer, * We are unable to release Windows bindists due to a compatibility issue which we didn't catch until after preparing the source distribution. * Binaries targeting Redhat distributions are currently not available Regardless, users for whom a distribution is available are encouraged to try this candidate as it fixes dozens of issues present in release candidate two. These include, * A type-checker panic triggered by use of Typeable on a kind-polymorphic type constructor (#11334) * A type-checker explosion where -XTypeInType would gobble up massive amounts of memory when used in a data instance (#11407) * Various issues involving unexpected laziness resulting in exception handlers not being invoked (#11555) * GHC now fails more gracefully when used with an older cabal-install release (#11558) * TypeInType now has proper documentation in the users guide (#11614) * The story surrounding type `RuntimeRep`s (formerly known as `Levity`) is now far better developed, closing several doors to unsafe behavior that TypeInType previously opened (#11473, #11723) * A long-standing bug in the constant-folding rules for `mod` for the `Word` type has been resolved (#11702) * Various issues introduced by OverloadedRecordFields have been fixed (#11662, #11401) * A regression in the typechecker resulting in the rejection of code in the `free` and `microlens` packages has been fixed (#11608) * A bug in the LLVM code generator which caused some programs to emit unbuildable LLVM IR has been fixed (#11649) * A bug where pattern synonyms defined in terms of a pattern match on a record would be rejected if the fields weren't written in the same order as they were defined has been resolved (#11633) * A bug in the runtime system's treatment of weak references which could result in segmentation faults in some cases has been fixed (#11108) * a variety of optimizations improving compiler performance have been merged * and many others Mac OS X users should be aware that the recent XCode 7.3 release ships with a broken `nm` utility which breaks the GHC build (#11744, #11823). Unfortunately, this candidate does not notice this brokenness and odd behavior can result. OS X users running XCode 7.3 are encouraged to open a ticket with Apple and build GHC with the `--with-nm=nm-classic` configure option until a fix is available. As mentioned earlier, there are a number of known issues with this candidate which will be addressed in release candidate four. These issues include, * A number of typechecker bugs (#11811, #11797, #11813, #11814) * A build issue seen on OS X (#11828) * Template Haskell lacks the ability to produce instances with OVERLAPP{ING,ABLE,ED} pragmas * Autoconf has inadequate version checks for libdw (#11820) * Typeable and hs-boot files interact poorly (#11824) * The build system doesn't check for the broken Apple `nm` utility, leading to unpredictable results (#11823, #11744) We hope to have release candidate four available by the middle of next week. Thanks to everyone who has contributed code, testing, builds, and bug reports thusfar! Cheers, - Ben

2 1

Accessing dictionaries from a GHC plugin
by Yannick Boesmans 22 Apr '16

22 Apr '16

Hi, I'm trying to develop a GHC plugin to transform effect handlers for free monads. I have created my own module with the free monad definitions. The goal is that if a user uses these definitions, my plugin will rewrite the handlers into a form which will allow fusion. For a first simple example I'm trying to transform the following code: handleNondet :: Functor g => Free (Nondet + g) a -> Free g [a] handleNondet = \y -> case y of Var x -> Var [x] Con op -> case op of Inl x -> case x of Or l r -> (handleNondet l >>= (\ll -> handleNondet r >>= (\rr -> Var (ll ++ rr)))) Inr x -> Con (fmap handleNondet x) into this: handleNondet :: Functor g => Free (Nondet + g) a -> Free g [a] handleNondet = foldFree genNondet algNondet genNondet :: Functor g => a -> Free g [a] genNondet x = Var [x] algNondet :: Functor g => (Nondet + g) (Free g [a]) -> Free g [a] algNondet op = case op of Inl x -> case x of Or l r -> (l >>= (\ll -> r >>= (\rr -> Var (ll ++ rr)))) Inr x -> Con x ----------------------------------------------------------------------------------------------------------------------------------- In my module with definitions, Free, Con, Var, the (+), Inl and Inr are defined and the foldFree function is defined. There is also a functor instance: instance (Functor f, Functor g) => Functor (f + g) The problem is that when trying to do this transformation in GHC Core, I only get a dictionary for the functor g, but not for Nondet or for (Nondet + g). What is need is of the form: (WhatMorphism.Free.$fFunctor+ @ Nondet @ g_a2MS Types.$fFunctorNondet $dFunctor_a2R9) and I have access to @ Nondet, @ g_a2MS and $dFunctor_a2R9, but I don't know how to find WhatMorphism.Free.$fFunctor+ and Types.$fFunctorNondet. I am trying to find out whether it is possible to find these dictionaries from a GHC Core plugin, or whether this has to happen in an earlier stage of the compilation. If it is possible, how would I go about it? And if it is not, where should I start looking to implement this functionality anyway? Regards, Yannick Boesmans

2 1

CmmSwitchTest
by Alex Dzyoba 22 Apr '16

22 Apr '16

Hello, I was trying to reproduce issue #11297 (CmmSwitchTest is broken on 32-bit platforms ) from Newcomers page and seems to stuck. I would like to ask for help here, but if there is a more suitable place to ask, please let me know. I've built current master (8c33cd4) stage2 compiler, removed "when(wordsize(32), expect_broken(11297))" from testsuite/tests/codeGen/should_run/all.T to see same errors as in issue and got this (unrelated?) assertion: =====> CmmSwitchTest(normal) 1 of 1 [0, 0, 0] cd ./codeGen/should_run && "/home/avd/ghc/inplace/test spaces/ghc-stage2" -o CmmSwitchTest CmmSwitchTest.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fshow-warning-groups -fno-ghci-history > CmmSwitchTest.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling Main ( CmmSwitchTest.hs, CmmSwitchTest.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160419 for i386-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/basicTypes/Literal.hs:224:75 in ghc:Literal 18446744073709551615 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for CmmSwitchTest(normal) Is there anything I can do with this? Is it because that test has 64-bit unboxed integers and I'm running it on 32-bit VM? Thanks, Alex

2 2

Possible compile time regression in GHC 8
by Sreenidhi Nair 21 Apr '16

21 Apr '16

Hello, While compiling the `record` package with ghc-8 rc3 with `stack build`, the memory usage went above 6gb and started trashing. But when `stack build --fast` (-O0) was being used the package compiled with maximum memory at 1.8gb. Also `stack build` works fine with ghc-7.10.3 with the build taking about 1.7gb. Attached is the stack file to reproduce the issue. Steps to reproduce: 1. Create a new directory and put the attached stack.yaml there. 2. run `stack build` - this will thrash after some time 3. run `stack build --fast` - this will succeed 4. run `stack build --resolver=ghc-7.10.3` - this will succeed as well

2 2

RE: [Diffusion] [Build Failed] rGHC55b1b85df424: Accept tcrun045 output
by Simon Peyton Jones 21 Apr '16

21 Apr '16

Ben: now are down to T4029 with max-bytes increased. Maybe just increase it? it's a flaky number because it depends on timing of major gc Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 20 April 2016 21:49 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: [Diffusion] [Build Failed] rGHC55b1b85df424: Accept tcrun045 output | | Harbormaster failed to build B9261: rGHC55b1b85df424: Accept tcrun045 output! | | BRANCHES | master | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC55b1b85df424 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite, Harbormaster

2 1

Re: Pattern synonym type flexibility
by David Feuer 20 Apr '16

20 Apr '16

I don't know what that means. There's no way to enforce duality at the term level. Enforcing it at the type level prevents me from doing what I want and serves no apparent purpose. Remember that pattern synonyms are all about providing nice syntax, not adding essential expressiveness. On Apr 20, 2016 1:41 PM, "Carter Schonwald" <carter.schonwald(a)gmail.com> wrote: Shouldn't the design simply be both directions are the dual of the other, and pure in some sense ? On Wednesday, April 20, 2016, David Feuer <david.feuer(a)gmail.com> wrote: > To some degree, it probably could be. But I believe that imposing any > substantial relationship between the smart constructor and the pattern > synonym is likely to fall squarely into the category of things that are > subtle, hard, and almost completely useless. In the arrangement I > suggested, people would be free to do some things that "don't make sense", > and that doesn't bother me in the least. > On Apr 20, 2016 1:27 PM, "Carter Schonwald" <carter.schonwald(a)gmail.com> > wrote: > >> Would that duality be related to the given vs wanted constraints ? >> >> On Wednesday, April 20, 2016, David Feuer <david.feuer(a)gmail.com> wrote: >> >>> As far as I can tell from the 7.10 documentation, it's impossible to >>> make a bidirectional pattern synonym used as a constructor have a >>> different type signature than when used as a pattern. Has this been >>> improved in 8.0? I really want something like >>> >>> class FastCons x xs | xs -> x where >>> fcons :: x -> xs -> xs >>> class FastViewL x xs | xs -> x where >>> fviewl :: xs -> ViewL x xs >>> >>> pattern x :<| xs <- (fviewl -> ConsL x xs) where >>> x :<| xs = fcons x xs >>> >>> This would allow users to learn just *one* name, :<|, that they can >>> use for sequences that are consable or viewable even if they may not >>> be the other. >>> >>> If this is not yet possible, then I think the most intuitive approach >>> is to sever the notions of "pattern synonym" and "smart constructor". >>> So I'd write >>> >>> pattern x :<| xs <- (fviewl -> ConsL x xs) >>> constructor (:<|) = fcons >>> >>> The current syntax could easily be desugared to produce *both* a >>> pattern synonym and a smart constructor in the bidirectional case. >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>

1 1

Pattern synonym type flexibility
by David Feuer 20 Apr '16

20 Apr '16

As far as I can tell from the 7.10 documentation, it's impossible to make a bidirectional pattern synonym used as a constructor have a different type signature than when used as a pattern. Has this been improved in 8.0? I really want something like class FastCons x xs | xs -> x where fcons :: x -> xs -> xs class FastViewL x xs | xs -> x where fviewl :: xs -> ViewL x xs pattern x :<| xs <- (fviewl -> ConsL x xs) where x :<| xs = fcons x xs This would allow users to learn just *one* name, :<|, that they can use for sequences that are consable or viewable even if they may not be the other. If this is not yet possible, then I think the most intuitive approach is to sever the notions of "pattern synonym" and "smart constructor". So I'd write pattern x :<| xs <- (fviewl -> ConsL x xs) constructor (:<|) = fcons The current syntax could easily be desugared to produce *both* a pattern synonym and a smart constructor in the bidirectional case.

2 3

RE: [Diffusion] [Build Failed] rGHC353d8ae6fafe: SCC analysis for instances as well as types/classes
by Simon Peyton Jones 20 Apr '16

20 Apr '16

Harbormaster below says that T11195 and T4029 fail; but they don't on my machine. But tcrun045 does.. patch for that coming Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 20 April 2016 16:08 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: [Diffusion] [Build Failed] rGHC353d8ae6fafe: SCC analysis for | instances as well as types/classes | | Harbormaster failed to build B9256: rGHC353d8ae6fafe: SCC analysis for | instances as well as types/classes! | | BRANCHES | master | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | GHC - Core/System FC (Auditor) | GHC - HsSyn/Parser (Auditor) | GHC - Renamer (Auditor) | GHC - Type checker/inferencer (Auditor) | GHC - Utilities (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC353d8ae6fafe | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite, GHC - Core/System FC, GHC - HsSyn/Parser, | GHC - Renamer, GHC - Type checker/inferencer, GHC - Utilities, | Harbormaster

1 0

Re: [GHC] #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..."
by George Colpitts 20 Apr '16

20 Apr '16

Yes, this is consistent with my investigation. The only place I could find in the source which emitted the message "Too late for parseStaticFlags..." was ghc/Main.hs. What puzzled me was why this is a Mac specific bug. On Tue, Apr 19, 2016 at 10:21 AM GHC <ghc-devs(a)haskell.org> wrote: > #10053: Regression on MacOS platform, error in ghci calling main after > loading > compiled code: "Too late for parseStaticFlags..." > -------------------------------------+------------------------------------- > Reporter: George | Owner: ak3n > Type: bug | Status: new > Priority: normal | Milestone: > Component: GHCi | Version: 7.10.1-rc2 > Resolution: | Keywords: > Operating System: MacOS X | Architecture: x86_64 > Type of failure: Incorrect result | (amd64) > at runtime | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by ak3n): > > Replying to [comment:17 bgamari]: > > ak3n, could you elaborate? > > This error is raised in > [https://github.com/ghc/ghc/blob/master/compiler/main/StaticFlags.hs#L80 > compiler/main/Staticflags.hs], when parseStaticFlags is called in > [https://github.com/ghc/ghc/blob/master/ghc/Main.hs#L113 ghc/Main.hs]. > > So, this code is called two times: on ghci start and on "main" input > statement. > > It looks like, linker replaces "main" from the loaded module > with "main" of ghc. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10053#comment:18> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0