Re: The build is broken (Solaris/x86, FreeBSD/{i386,amd64})
> I think Simon Marlow is even more conservative, and > does his validate builds in a separate tree so he catches missing files. I thought everyone is doing that. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git
Hi Herbert, > After a short conversion with Austin and Edward it appears that the > sensible course of action with respect towards moving to a proper Git > submodule set-up is to fold-in the 5 Git repos listed below (which btw > are all GHC wired-in packages) directly into ghc.git (the same way > testsuite.git was a few months ago): This is just a confirmation. I have no opinion on this. Recalling the discussion in the last summer, I understood GHC project will start using git subtree, not git submodule. But it seems to me this is my misunderstanding. What was the conclusion of that discussion? And would you tell me why submodule was chosen? --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Git problem
Hey Simon, If you have no Haddock changes, try cd'ing into the haddock directory and doing a hard reset to the remote origin (so something like git reset --hard origin/master *INSIDE HADDOCK*), and then changing back to the main directory and git add'ing the directory. Edward Excerpts from Simon Peyton Jones's message of 2014-04-14 02:13:02 -0700: > Friends > I'm stuck with Git. Help please! > Simon > > I tried to do a 'git stash pop', having just done a 'git pull' from the > master repo. I got this: > > simonpj@cam-05-unx:~/code/HEAD-2$ git stash pop > > warning: Failed to merge submodule utils/haddock (commits don't follow > merge-base) > > Auto-merging utils/haddock > > CONFLICT (submodule): Merge conflict in utils/haddock > > Auto-merging compiler/typecheck/TcRnMonad.lhs > Now git status says > > simonpj@cam-05-unx:~/code/HEAD-2$ git status > > # On branch master > > # Your branch is ahead of 'origin/master' by 2 commits. > > # > > # Changes to be committed: > > # (use "git reset HEAD ..." to unstage) > > # > > #modified: compiler/typecheck/TcMType.lhs > > #modified: compiler/typecheck/TcRnMonad.lhs > > #modified: compiler/typecheck/TcSimplify.lhs > > #modified: compiler/typecheck/TcUnify.lhs > > # > > # Unmerged paths: > > # (use "git reset HEAD ..." to unstage) > > # (use "git add/rm ..." as appropriate to mark resolution) > > # > > #both modified: utils/haddock > The modified files are right. It's the "both modified utils/haddock" that is > messing me up. > I'm not modifying haddock! I just want to say "take the master haddock", but > I don't know how. I tried 'git checkout utils/haddock' but that just led do > `git status' saying > > #modified: utils/haddock (new commits) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: The build is broken (Solaris/x86, FreeBSD/{i386,amd64})
Hey Gergo, It looks like this failure came from one of your commits, which didn't include a submodule update. One trick that I find very useful for making sure that I haven't missed any files when submitting a patch is to always run 'git status' before I push, and carefully look at all the output, especially staged but not committed changes. I think Simon Marlow is even more conservative, and does his validate builds in a separate tree so he catches missing files. Edward Excerpts from Herbert Valerio Riedel's message of 2014-04-14 00:17:51 -0700: > Hi, > > (probably) fixed by > > > http://git.haskell.org/ghc.git/commitdiff/b4a820f97e48199a92f5ce7216731500f9a841c9 > > > > On 2014-04-14 at 09:15:42 +0200, Páli Gábor János wrote: > > [...] > > > utils/haddock/src/Haddock/Interface/Create.hs:367:44: > > Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' > > with '(a1, Located (HsBind id))' > > Expected type: TyClDecl Name -> Bag (a1, Located (HsBind id)) > > Actual type: TyClDecl Name -> LHsBinds Name > > Relevant bindings include > > defs :: [Located (HsDecl id)] > > (bound at utils/haddock/src/Haddock/Interface/Create.hs:367:5) > > In the second argument of '(.)', namely 'tcdMeths' > > In the second argument of '(.)', namely 'bagToList . tcdMeths' > > utils/haddock/src/Haddock/Interface/Create.hs:393:22: > > Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' > > with '(a0, Located (HsBind Name))' > > Expected type: HsValBindsLR Name Name > >-> [(a0, Located (HsBind Name))] > > Actual type: HsValBindsLR Name Name -> [LHsBindLR Name Name] > > In the first argument of '(.)', namely 'valbinds' > > In the second argument of '(.)', namely 'valbinds . hs_valds' > > gmake[1]: *** [utils/haddock/dist/build/Haddock/Interface/Create.dyn_o] > > Error 1 > > gmake: *** [all] Error 2 > > > > Please consult the details at > > > > http://haskell.inf.elte.hu/builders/solaris-x86-head/28/10.html > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Help with coercion & roles?
This explanation-with-example is very helpful. Thanks, Richard! I'll noodle some more. A fairly simple & robust solution may be to add `Cast` to my expression GADT. -- Conal On Mon, Apr 14, 2014 at 2:02 PM, Richard Eisenberg wrote: > So what do you think? Is there a sound coercion I can build for `co'`? > > > In a word, "no". The problem is that E, as you describe, is a GADT. > Therefore, it cares exactly which types it is parameterized by. We can see > this in evidence in the dump, which labels E's second parameter as nominal. > To draw out the problem, let's look at a simpler example: > > > newtype Age = MkAge Int > > data G a where > > MkGInt :: G Int > > MkGAge :: G Age > > Here, `G` would similarly get a nominal role, because we can't lift > representational coercions (such as NTCo:Age :: Age ~R Int) through the `G` > type constructor. If we could, we could then have (MkGAge |> ...) :: G Int, > which goes against our definition of G -- the only value inhabitant of G > Int should be MkGInt. > > The best you can do here is to try to raise the inner coercion to be > nominal, by unSubCo_maybe. If that fails, I think you've gone beyond the > ability of GHC's type system. > > Of course, I would like to help you with a way forward -- let me know if > there's a way I can. > > Richard > > On Apr 14, 2014, at 4:12 PM, Conal Elliott wrote: > > Hi Richard, > > I'm working on compiling Haskell to hardware, as outlined at > https://github.com/conal/lambda-ccc/blob/master/doc/notes.md (with links > to a few recent blog posts). The first step is to convert Core into other > Core that evaluates to a reified form, represented as a type-parametrized > GADT. This GADT (in `LambdaCCC.Lambda`): > > > data E :: (* -> *) -> (* -> *) where ... > > The parameter is also type-parametrized, and is for the primitives. I have > such a type designed for hardware generation (in `LambdaCCC.Prim`) > > > data Prim :: * -> * where ... > > and then the combination of the two: > > > type EP = E Prim > > So that's what `EP` is. > > With `-ddump-tc`, I get > > > TYPE CONSTRUCTORS > > ... > > E :: (* -> *) -> * -> * > > data E ($a::* -> *) $b > > No C type associated > > Roles: [representational, nominal] > > RecFlag NonRecursive, Not promotable > > = ... > > EP :: * -> * > > type EP = E Prim > > The use of `EP` rather than the more general `E` is only temporary, while > I'm learning more details of Core (and of HERMIT which I'm using to > manipulate Core). > > I'm now working on reification in the presence of casts. The rule I'm > trying to implement is > > > evalEP e |> co --> evalEP (e |> co'). > > Here, `evalEP :: EP a -> a` and `co :: a ~ b`, so `co' :: EP a ~ EP b`. > > I'm trying to build `co'` from `co`, which led to these questions. > > So what do you think? Is there a sound coercion I can build for `co'`? > > -- Conal > > > On Mon, Apr 14, 2014 at 11:54 AM, Richard Eisenberg wrote: > >> Hi Conal, >> >> In your case, the `_N` on the argument to NTCo:HasIf[0] is correct -- the >> `HasIf` class indeed has a nominal parameter. So, it seems that this part, >> at least, is OK. >> >> What's the -ddump-tc on EP? Is EP's role nominal? (I think so, given what >> you're saying.) If that's the case, you won't be able to pass the result of >> NTCo:HasIf[0] to a coercion built from EP. >> >> Popping up a level, what are you trying to do here? If EP's role is >> indeed nominal, then I don't believe there's a fix here, as the coercion it >> seems you're trying to build may be unsound. (It looks to me like you want >> something proving `EP (Bool -> Bool -> Bool -> Bool) ~R EP (HasIf Bool)`, >> but if EP's role is nominal, then this is indeed bogus.) >> >> Richard >> >> On Apr 14, 2014, at 2:23 PM, Conal Elliott wrote: >> >> Thanks for the pointers! I don't quite know how to get to the form you >> recommend from the existing coercion, which is `Simple.NTCo:HasIf[0] >> _N`. (Note the `_N`.) I got that coercion in GHC 7.8.2 from >> the following code: >> >> > class HasIf a where >> > ifThenElse :: Bool -> a -> a -> a >> > >> > instance HasIf Bool where >> > ifThenElse i t e = (i && t) || (not i && e) >> >> With `--dump-tc`, I see >> >> > TYPE SIGNATURES >> > TYPE CONSTRUCTORS >> > HasIf :: * -> Constraint >> > class HasIf a >> > Roles: [nominal] >> > RecFlag NonRecursive >> > ifThenElse :: Bool -> a -> a -> a >> > COERCION AXIOMS >> > axiom Main.NTCo:HasIf :: HasIf a = Bool -> a -> a -> a >> > INSTANCES >> > instance HasIf Bool -- Defined at ../test/HasIf.hs:4:10 >> >> Do I need to convert the nominal coercion I got from GHC >> (`Simple.NTCo:HasIf[0] _N` in this case) to a >> representational one? If so, how? >> My current formulation (tweaked to use `mkSubCo` and `mkAppCo`) is to >> apply `mkAppCo (mkSubCo (Refl Nominal ep))` to the given coercion, which >> then produces >> >> > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R >> >> And still I get "Role incompatibility: expected no
Re: Help with coercion & roles?
> So what do you think? Is there a sound coercion I can build for `co'`? In a word, "no". The problem is that E, as you describe, is a GADT. Therefore, it cares exactly which types it is parameterized by. We can see this in evidence in the dump, which labels E's second parameter as nominal. To draw out the problem, let's look at a simpler example: > newtype Age = MkAge Int > data G a where > MkGInt :: G Int > MkGAge :: G Age Here, `G` would similarly get a nominal role, because we can't lift representational coercions (such as NTCo:Age :: Age ~R Int) through the `G` type constructor. If we could, we could then have (MkGAge |> ...) :: G Int, which goes against our definition of G -- the only value inhabitant of G Int should be MkGInt. The best you can do here is to try to raise the inner coercion to be nominal, by unSubCo_maybe. If that fails, I think you've gone beyond the ability of GHC's type system. Of course, I would like to help you with a way forward -- let me know if there's a way I can. Richard On Apr 14, 2014, at 4:12 PM, Conal Elliott wrote: > Hi Richard, > > I'm working on compiling Haskell to hardware, as outlined at > https://github.com/conal/lambda-ccc/blob/master/doc/notes.md (with links to a > few recent blog posts). The first step is to convert Core into other Core > that evaluates to a reified form, represented as a type-parametrized GADT. > This GADT (in `LambdaCCC.Lambda`): > > > data E :: (* -> *) -> (* -> *) where ... > > The parameter is also type-parametrized, and is for the primitives. I have > such a type designed for hardware generation (in `LambdaCCC.Prim`) > > > data Prim :: * -> * where ... > > and then the combination of the two: > > > type EP = E Prim > > So that's what `EP` is. > > With `-ddump-tc`, I get > > > TYPE CONSTRUCTORS > > ... > > E :: (* -> *) -> * -> * > > data E ($a::* -> *) $b > > No C type associated > > Roles: [representational, nominal] > > RecFlag NonRecursive, Not promotable > > = ... > > EP :: * -> * > > type EP = E Prim > > The use of `EP` rather than the more general `E` is only temporary, while I'm > learning more details of Core (and of HERMIT which I'm using to manipulate > Core). > > I'm now working on reification in the presence of casts. The rule I'm trying > to implement is > > > evalEP e |> co --> evalEP (e |> co'). > > Here, `evalEP :: EP a -> a` and `co :: a ~ b`, so `co' :: EP a ~ EP b`. > > I'm trying to build `co'` from `co`, which led to these questions. > > So what do you think? Is there a sound coercion I can build for `co'`? > > -- Conal > > > On Mon, Apr 14, 2014 at 11:54 AM, Richard Eisenberg > wrote: > Hi Conal, > > In your case, the `_N` on the argument to NTCo:HasIf[0] is correct -- the > `HasIf` class indeed has a nominal parameter. So, it seems that this part, at > least, is OK. > > What's the -ddump-tc on EP? Is EP's role nominal? (I think so, given what > you're saying.) If that's the case, you won't be able to pass the result of > NTCo:HasIf[0] to a coercion built from EP. > > Popping up a level, what are you trying to do here? If EP's role is indeed > nominal, then I don't believe there's a fix here, as the coercion it seems > you're trying to build may be unsound. (It looks to me like you want > something proving `EP (Bool -> Bool -> Bool -> Bool) ~R EP (HasIf Bool)`, but > if EP's role is nominal, then this is indeed bogus.) > > Richard > > On Apr 14, 2014, at 2:23 PM, Conal Elliott wrote: > >> Thanks for the pointers! I don't quite know how to get to the form you >> recommend from the existing coercion, which is `Simple.NTCo:HasIf[0] >> _N`. (Note the `_N`.) I got that coercion in GHC 7.8.2 from >> the following code: >> >> > class HasIf a where >> > ifThenElse :: Bool -> a -> a -> a >> > >> > instance HasIf Bool where >> > ifThenElse i t e = (i && t) || (not i && e) >> >> With `--dump-tc`, I see >> >> > TYPE SIGNATURES >> > TYPE CONSTRUCTORS >> > HasIf :: * -> Constraint >> > class HasIf a >> > Roles: [nominal] >> > RecFlag NonRecursive >> > ifThenElse :: Bool -> a -> a -> a >> > COERCION AXIOMS >> > axiom Main.NTCo:HasIf :: HasIf a = Bool -> a -> a -> a >> > INSTANCES >> > instance HasIf Bool -- Defined at ../test/HasIf.hs:4:10 >> >> Do I need to convert the nominal coercion I got from GHC >> (`Simple.NTCo:HasIf[0] _N` in this case) to a >> representational one? If so, how? >> My current formulation (tweaked to use `mkSubCo` and `mkAppCo`) is to apply >> `mkAppCo (mkSubCo (Refl Nominal ep))` to the given coercion, which then >> produces >> >> > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R >> >> And still I get "Role incompatibility: expected nominal, got >> representational in `Sym (Simple.NTCo:HasIf[0] _N)`". >> >> I also tried wrapping `mkSubCo` around the entire coercion (applying >> `mkSubCo . mkAppCo (Refl Nominal ep)`), and I see the same result: >> >> > (LambdaCCC.Lamb
Re: Help with coercion & roles?
Hi Richard, I'm working on compiling Haskell to hardware, as outlined at https://github.com/conal/lambda-ccc/blob/master/doc/notes.md (with links to a few recent blog posts). The first step is to convert Core into other Core that evaluates to a reified form, represented as a type-parametrized GADT. This GADT (in `LambdaCCC.Lambda`): > data E :: (* -> *) -> (* -> *) where ... The parameter is also type-parametrized, and is for the primitives. I have such a type designed for hardware generation (in `LambdaCCC.Prim`) > data Prim :: * -> * where ... and then the combination of the two: > type EP = E Prim So that's what `EP` is. With `-ddump-tc`, I get > TYPE CONSTRUCTORS > ... > E :: (* -> *) -> * -> * > data E ($a::* -> *) $b > No C type associated > Roles: [representational, nominal] > RecFlag NonRecursive, Not promotable > = ... > EP :: * -> * > type EP = E Prim The use of `EP` rather than the more general `E` is only temporary, while I'm learning more details of Core (and of HERMIT which I'm using to manipulate Core). I'm now working on reification in the presence of casts. The rule I'm trying to implement is > evalEP e |> co --> evalEP (e |> co'). Here, `evalEP :: EP a -> a` and `co :: a ~ b`, so `co' :: EP a ~ EP b`. I'm trying to build `co'` from `co`, which led to these questions. So what do you think? Is there a sound coercion I can build for `co'`? -- Conal On Mon, Apr 14, 2014 at 11:54 AM, Richard Eisenberg wrote: > Hi Conal, > > In your case, the `_N` on the argument to NTCo:HasIf[0] is correct -- the > `HasIf` class indeed has a nominal parameter. So, it seems that this part, > at least, is OK. > > What's the -ddump-tc on EP? Is EP's role nominal? (I think so, given what > you're saying.) If that's the case, you won't be able to pass the result of > NTCo:HasIf[0] to a coercion built from EP. > > Popping up a level, what are you trying to do here? If EP's role is indeed > nominal, then I don't believe there's a fix here, as the coercion it seems > you're trying to build may be unsound. (It looks to me like you want > something proving `EP (Bool -> Bool -> Bool -> Bool) ~R EP (HasIf Bool)`, > but if EP's role is nominal, then this is indeed bogus.) > > Richard > > On Apr 14, 2014, at 2:23 PM, Conal Elliott wrote: > > Thanks for the pointers! I don't quite know how to get to the form you > recommend from the existing coercion, which is `Simple.NTCo:HasIf[0] > _N`. (Note the `_N`.) I got that coercion in GHC 7.8.2 from > the following code: > > > class HasIf a where > > ifThenElse :: Bool -> a -> a -> a > > > > instance HasIf Bool where > > ifThenElse i t e = (i && t) || (not i && e) > > With `--dump-tc`, I see > > > TYPE SIGNATURES > > TYPE CONSTRUCTORS > > HasIf :: * -> Constraint > > class HasIf a > > Roles: [nominal] > > RecFlag NonRecursive > > ifThenElse :: Bool -> a -> a -> a > > COERCION AXIOMS > > axiom Main.NTCo:HasIf :: HasIf a = Bool -> a -> a -> a > > INSTANCES > > instance HasIf Bool -- Defined at ../test/HasIf.hs:4:10 > > Do I need to convert the nominal coercion I got from GHC > (`Simple.NTCo:HasIf[0] _N` in this case) to a > representational one? If so, how? > My current formulation (tweaked to use `mkSubCo` and `mkAppCo`) is to > apply `mkAppCo (mkSubCo (Refl Nominal ep))` to the given coercion, which > then produces > > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R > > And still I get "Role incompatibility: expected nominal, got > representational in `Sym (Simple.NTCo:HasIf[0] _N)`". > > I also tried wrapping `mkSubCo` around the entire coercion (applying > `mkSubCo . mkAppCo (Refl Nominal ep)`), and I see the same result: > > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R > > -- Conal > > > > On Mon, Apr 14, 2014 at 4:39 AM, Richard Eisenberg wrote: > >> I agree with Simon, but just `Sub` the `_N`, not the >> whole coercion. >> >> There are actually two problems here. The one Simon identified, and also >> the fact that Simple.NTCo:HasIf[0] produces a representational coercion. >> How do I know? Because of the `NT` -- it's a newtype axiom and must produce >> representational coercions. Furthermore, unless the newtype definition is >> inferred to require a nominal parameter, the newtype would expect a >> representational coercion, not the nominal one you are passing. Check the >> dump (using -ddump-tc) of the newtype axiom to be sure. >> >> Though putting a `Sub` on `` and changing the Refl constructor on >> `` would work, you would then be violating an invariant of GHC's >> Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl >> (TyConApp tc [])) ...`. >> >> In sum, here is the coercion I think you want: >> >> (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R >> >> This is one of the problems with roles -- they are *very* fiddly within >> GHC, and it's hard for a non-expert in roles to get them right. >> >> Have you seen docs/core-spec/core-spec.pdf? That is updated w.
Re: Help with coercion & roles?
Hi Conal, In your case, the `_N` on the argument to NTCo:HasIf[0] is correct -- the `HasIf` class indeed has a nominal parameter. So, it seems that this part, at least, is OK. What's the -ddump-tc on EP? Is EP's role nominal? (I think so, given what you're saying.) If that's the case, you won't be able to pass the result of NTCo:HasIf[0] to a coercion built from EP. Popping up a level, what are you trying to do here? If EP's role is indeed nominal, then I don't believe there's a fix here, as the coercion it seems you're trying to build may be unsound. (It looks to me like you want something proving `EP (Bool -> Bool -> Bool -> Bool) ~R EP (HasIf Bool)`, but if EP's role is nominal, then this is indeed bogus.) Richard On Apr 14, 2014, at 2:23 PM, Conal Elliott wrote: > Thanks for the pointers! I don't quite know how to get to the form you > recommend from the existing coercion, which is `Simple.NTCo:HasIf[0] > _N`. (Note the `_N`.) I got that coercion in GHC 7.8.2 from > the following code: > > > class HasIf a where > > ifThenElse :: Bool -> a -> a -> a > > > > instance HasIf Bool where > > ifThenElse i t e = (i && t) || (not i && e) > > With `--dump-tc`, I see > > > TYPE SIGNATURES > > TYPE CONSTRUCTORS > > HasIf :: * -> Constraint > > class HasIf a > > Roles: [nominal] > > RecFlag NonRecursive > > ifThenElse :: Bool -> a -> a -> a > > COERCION AXIOMS > > axiom Main.NTCo:HasIf :: HasIf a = Bool -> a -> a -> a > > INSTANCES > > instance HasIf Bool -- Defined at ../test/HasIf.hs:4:10 > > Do I need to convert the nominal coercion I got from GHC > (`Simple.NTCo:HasIf[0] _N` in this case) to a > representational one? If so, how? > My current formulation (tweaked to use `mkSubCo` and `mkAppCo`) is to apply > `mkAppCo (mkSubCo (Refl Nominal ep))` to the given coercion, which then > produces > > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R > > And still I get "Role incompatibility: expected nominal, got representational > in `Sym (Simple.NTCo:HasIf[0] _N)`". > > I also tried wrapping `mkSubCo` around the entire coercion (applying `mkSubCo > . mkAppCo (Refl Nominal ep)`), and I see the same result: > > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R > > -- Conal > > > On Mon, Apr 14, 2014 at 4:39 AM, Richard Eisenberg wrote: > I agree with Simon, but just `Sub` the `_N`, not the > whole coercion. > > There are actually two problems here. The one Simon identified, and also the > fact that Simple.NTCo:HasIf[0] produces a representational coercion. How do I > know? Because of the `NT` -- it's a newtype axiom and must produce > representational coercions. Furthermore, unless the newtype definition is > inferred to require a nominal parameter, the newtype would expect a > representational coercion, not the nominal one you are passing. Check the > dump (using -ddump-tc) of the newtype axiom to be sure. > > Though putting a `Sub` on `` and changing the Refl constructor on > `` would work, you would then be violating an invariant of GHC's > Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl (TyConApp > tc [])) ...`. > > In sum, here is the coercion I think you want: > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R > > This is one of the problems with roles -- they are *very* fiddly within GHC, > and it's hard for a non-expert in roles to get them right. > > Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles and > may be of help. > > Let me know if I can help further! > Richard > > On Apr 14, 2014, at 5:45 AM, Simon Peyton Jones wrote: > >> I think you need a ‘Sub’. >> >> A cast (e `cast` g) requires a representational coercion. I think you have >> given it a (stronger) nominal one. Sub gets from one to t’other. >> >> Simon >> >> From: Glasgow-haskell-users >> [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Conal Elliott >> Sent: 14 April 2014 06:00 >> To: ghc-devs@haskell.org; glasgow-haskell-us...@haskell.org >> Subject: Help with coercion & roles? >> >> I’m working on a GHC plugin (as part of my Haskell-to-hardware work) and >> running into trouble with coercions & roles. Error message from Core Lint: >> >> Warning: In the expression: >> >> >> LambdaCCC.Lambda.lamvP# >> @ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) >> @ (Simple.HasIf GHC.Types.Bool) >> >> "tpl"# >> ((LambdaCCC.Lambda.varP# >> @ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) >> "tpl"#) >> >> `cast` (_N (Sym (Simple.NTCo:HasIf[0] >> _N)) >> >> ∷ LambdaCCC.Lambda.EP >> (GHC.Types.Bool >> >>→ GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) >> >> ~# >> LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) >> >> >> Role incompatibility: expected nominal, got representational >> >> in _N (Sym (Simple
Re: Help with coercion & roles?
Thanks for the pointers! I don't quite know how to get to the form you recommend from the existing coercion, which is `Simple.NTCo:HasIf[0] _N`. (Note the `_N`.) I got that coercion in GHC 7.8.2 from the following code: > class HasIf a where > ifThenElse :: Bool -> a -> a -> a > > instance HasIf Bool where > ifThenElse i t e = (i && t) || (not i && e) With `--dump-tc`, I see > TYPE SIGNATURES > TYPE CONSTRUCTORS > HasIf :: * -> Constraint > class HasIf a > Roles: [nominal] > RecFlag NonRecursive > ifThenElse :: Bool -> a -> a -> a > COERCION AXIOMS > axiom Main.NTCo:HasIf :: HasIf a = Bool -> a -> a -> a > INSTANCES > instance HasIf Bool -- Defined at ../test/HasIf.hs:4:10 Do I need to convert the nominal coercion I got from GHC (`Simple.NTCo:HasIf[0] _N` in this case) to a representational one? If so, how? My current formulation (tweaked to use `mkSubCo` and `mkAppCo`) is to apply `mkAppCo (mkSubCo (Refl Nominal ep))` to the given coercion, which then produces > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R And still I get "Role incompatibility: expected nominal, got representational in `Sym (Simple.NTCo:HasIf[0] _N)`". I also tried wrapping `mkSubCo` around the entire coercion (applying `mkSubCo . mkAppCo (Refl Nominal ep)`), and I see the same result: > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R -- Conal On Mon, Apr 14, 2014 at 4:39 AM, Richard Eisenberg wrote: > I agree with Simon, but just `Sub` the `_N`, not the > whole coercion. > > There are actually two problems here. The one Simon identified, and also > the fact that Simple.NTCo:HasIf[0] produces a representational coercion. > How do I know? Because of the `NT` -- it's a newtype axiom and must produce > representational coercions. Furthermore, unless the newtype definition is > inferred to require a nominal parameter, the newtype would expect a > representational coercion, not the nominal one you are passing. Check the > dump (using -ddump-tc) of the newtype axiom to be sure. > > Though putting a `Sub` on `` and changing the Refl constructor on > `` would work, you would then be violating an invariant of GHC's > Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl > (TyConApp tc [])) ...`. > > In sum, here is the coercion I think you want: > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R > > This is one of the problems with roles -- they are *very* fiddly within > GHC, and it's hard for a non-expert in roles to get them right. > > Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles > and may be of help. > > Let me know if I can help further! > Richard > > On Apr 14, 2014, at 5:45 AM, Simon Peyton Jones > wrote: > > I think you need a ‘Sub’. > > A cast (e `cast` g) requires a representational coercion. I think you > have given it a (stronger) nominal one. Sub gets from one to t’other. > > Simon > > *From:* Glasgow-haskell-users [mailto:glasgow- > haskell-users-boun...@haskell.org] *On Behalf Of *Conal Elliott > *Sent:* 14 April 2014 06:00 > *To:* ghc-devs@haskell.org; glasgow-haskell-us...@haskell.org > *Subject:* Help with coercion & roles? > > > I’m working on a GHC plugin (as part of my Haskell-to-hardware work) and > running into trouble with coercions & roles. Error message from Core Lint: > > Warning: In the expression: > > > > LambdaCCC.Lambda.lamvP# > > @ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) > > @ (Simple.HasIf GHC.Types.Bool) > > "tpl"# > > ((LambdaCCC.Lambda.varP# > > @ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) > > "tpl"#) > > `cast` (_N (Sym (Simple.NTCo:HasIf[0] > _N)) > > ∷ LambdaCCC.Lambda.EP > > (GHC.Types.Bool > >→ GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) > > ~# > > LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) > > Role incompatibility: expected nominal, got representational > > in _N (Sym (Simple.NTCo:HasIf[0] _N)) > > Do you see anything inconsistent/incompatible in the coercions or roles > above? I constructed the nominal EP Refl coercion, and applied it (AppCo) > an existing coercion of a simpler type. > > Thanks, > -- Conal > ___ > Glasgow-haskell-users mailing list > glasgow-haskell-us...@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Help with coercion & roles?
I agree with Simon, but just `Sub` the `_N`, not the whole coercion. There are actually two problems here. The one Simon identified, and also the fact that Simple.NTCo:HasIf[0] produces a representational coercion. How do I know? Because of the `NT` -- it's a newtype axiom and must produce representational coercions. Furthermore, unless the newtype definition is inferred to require a nominal parameter, the newtype would expect a representational coercion, not the nominal one you are passing. Check the dump (using -ddump-tc) of the newtype axiom to be sure. Though putting a `Sub` on `` and changing the Refl constructor on `` would work, you would then be violating an invariant of GHC's Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl (TyConApp tc [])) ...`. In sum, here is the coercion I think you want: (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R This is one of the problems with roles -- they are *very* fiddly within GHC, and it's hard for a non-expert in roles to get them right. Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles and may be of help. Let me know if I can help further! Richard On Apr 14, 2014, at 5:45 AM, Simon Peyton Jones wrote: > I think you need a ‘Sub’. > > A cast (e `cast` g) requires a representational coercion. I think you have > given it a (stronger) nominal one. Sub gets from one to t’other. > > Simon > > From: Glasgow-haskell-users > [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Conal Elliott > Sent: 14 April 2014 06:00 > To: ghc-devs@haskell.org; glasgow-haskell-us...@haskell.org > Subject: Help with coercion & roles? > > I’m working on a GHC plugin (as part of my Haskell-to-hardware work) and > running into trouble with coercions & roles. Error message from Core Lint: > > Warning: In the expression: > > LambdaCCC.Lambda.lamvP# > @ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) > @ (Simple.HasIf GHC.Types.Bool) > "tpl"# > ((LambdaCCC.Lambda.varP# > @ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) > "tpl"#) > `cast` (_N (Sym (Simple.NTCo:HasIf[0] > _N)) > ∷ LambdaCCC.Lambda.EP > (GHC.Types.Bool >→ GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) > ~# > LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) > > Role incompatibility: expected nominal, got representational > in _N (Sym (Simple.NTCo:HasIf[0] _N)) > Do you see anything inconsistent/incompatible in the coercions or roles > above? I constructed the nominal EP Refl coercion, and applied it (AppCo) an > existing coercion of a simpler type. > > Thanks, > > -- Conal > ___ > Glasgow-haskell-users mailing list > glasgow-haskell-us...@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Git problem
On 2014-04-14 at 11:13:02 +0200, Simon Peyton Jones wrote: [...] > #both modified: utils/haddock > The modified files are right. It's the "both modified utils/haddock" that is > messing me up. > I'm not modifying haddock! I just want to say "take the master haddock", but > I don't know how. I tried 'git checkout utils/haddock' but that just led do > `git status' saying > > #modified: utils/haddock (new commits) Fyi, the git equivalent of saying "take the master haddock" (where 'master' refers to 'master' of 'haddock.git'): # checkout master of haddock.git: git submodule update --remote utils/haddock # register state (= submod commit-id) of utils/haddock for next commit git add utils/haddock HTH, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Help with coercion & roles?
I think you need a ‘Sub’. A cast (e `cast` g) requires a representational coercion. I think you have given it a (stronger) nominal one. Sub gets from one to t’other. Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Conal Elliott Sent: 14 April 2014 06:00 To: ghc-devs@haskell.org; glasgow-haskell-us...@haskell.org Subject: Help with coercion & roles? I’m working on a GHC plugin (as part of my Haskell-to-hardware work) and running into trouble with coercions & roles. Error message from Core Lint: Warning: In the expression: LambdaCCC.Lambda.lamvP# @ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) @ (Simple.HasIf GHC.Types.Bool) "tpl"# ((LambdaCCC.Lambda.varP# @ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) "tpl"#) `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) ∷ LambdaCCC.Lambda.EP (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) ~# LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) Role incompatibility: expected nominal, got representational in _N (Sym (Simple.NTCo:HasIf[0] _N)) Do you see anything inconsistent/incompatible in the coercions or roles above? I constructed the nominal EP Refl coercion, and applied it (AppCo) an existing coercion of a simpler type. Thanks, -- Conal ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Git problem
Friends I'm stuck with Git. Help please! Simon I tried to do a 'git stash pop', having just done a 'git pull' from the master repo. I got this: simonpj@cam-05-unx:~/code/HEAD-2$ git stash pop warning: Failed to merge submodule utils/haddock (commits don't follow merge-base) Auto-merging utils/haddock CONFLICT (submodule): Merge conflict in utils/haddock Auto-merging compiler/typecheck/TcRnMonad.lhs Now git status says simonpj@cam-05-unx:~/code/HEAD-2$ git status # On branch master # Your branch is ahead of 'origin/master' by 2 commits. # # Changes to be committed: # (use "git reset HEAD ..." to unstage) # #modified: compiler/typecheck/TcMType.lhs #modified: compiler/typecheck/TcRnMonad.lhs #modified: compiler/typecheck/TcSimplify.lhs #modified: compiler/typecheck/TcUnify.lhs # # Unmerged paths: # (use "git reset HEAD ..." to unstage) # (use "git add/rm ..." as appropriate to mark resolution) # #both modified: utils/haddock The modified files are right. It's the "both modified utils/haddock" that is messing me up. I'm not modifying haddock! I just want to say "take the master haddock", but I don't know how. I tried 'git checkout utils/haddock' but that just led do `git status' saying #modified: utils/haddock (new commits) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git
Sounds good to me too.
On Mon, Apr 14, 2014 at 10:22 AM, Simon Peyton Jones
wrote:
> OK with me! Sounds simpler.
>
> Simon
>
> | -Original Message-
> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> | Herbert Valerio Riedel
> | Sent: 13 April 2014 08:59
> | To: ghc-devs
> | Cc: Austin Seipp
> | Subject: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-
> | template into ghc.git
> |
> | Hello *,
> |
> | Now that GHC 7.8.[12] is out of the door, the Git reorganization can be
> | tackled further...
> |
> | After a short conversion with Austin and Edward it appears that the
> | sensible course of action with respect towards moving to a proper Git
> | submodule set-up is to fold-in the 5 Git repos listed below (which btw
> | are all GHC wired-in packages) directly into ghc.git (the same way
> | testsuite.git was a few months ago):
> |
> | - base
> | - ghc-prim
> | - integer-gmp
> | - integer-simple
> | - template-haskell
> |
> | IMO, the benefit/cost ratio of simplifying the workflow outweighs the
> | benefit/cost ratio of turning those into proper Git submodules.
> |
> | This incremental step towards a fully git-bisect-able ghc.git does
> | already allow bisecting to work on a larger time-range than it does
> | now, as those wired-in packages are the most likely to break
> | compilation if out-of-sync with ghc.git.
> |
> | If no objections are raised, I'm planning to implement this change next
> | weekend (April 19th/20th).
> |
> | Any comments/questions/...?
> |
> | Cheers,
> | hvr
> |
> |
> |
> | PS: After this step, the next remaining step would be to turn the
> | remaining not-yet-submodule Git repos into proper submodule Repos
> | (like haddock.git) and figure out how to get the sync-all
> | convenience-tooling a bit more submodule friendly...
> | ___
> | ghc-devs mailing list
> | ghc-devs@haskell.org
> | http://www.haskell.org/mailman/listinfo/ghc-devs
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git
OK with me! Sounds simpler.
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
| Herbert Valerio Riedel
| Sent: 13 April 2014 08:59
| To: ghc-devs
| Cc: Austin Seipp
| Subject: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-
| template into ghc.git
|
| Hello *,
|
| Now that GHC 7.8.[12] is out of the door, the Git reorganization can be
| tackled further...
|
| After a short conversion with Austin and Edward it appears that the
| sensible course of action with respect towards moving to a proper Git
| submodule set-up is to fold-in the 5 Git repos listed below (which btw
| are all GHC wired-in packages) directly into ghc.git (the same way
| testsuite.git was a few months ago):
|
| - base
| - ghc-prim
| - integer-gmp
| - integer-simple
| - template-haskell
|
| IMO, the benefit/cost ratio of simplifying the workflow outweighs the
| benefit/cost ratio of turning those into proper Git submodules.
|
| This incremental step towards a fully git-bisect-able ghc.git does
| already allow bisecting to work on a larger time-range than it does
| now, as those wired-in packages are the most likely to break
| compilation if out-of-sync with ghc.git.
|
| If no objections are raised, I'm planning to implement this change next
| weekend (April 19th/20th).
|
| Any comments/questions/...?
|
| Cheers,
| hvr
|
|
|
| PS: After this step, the next remaining step would be to turn the
| remaining not-yet-submodule Git repos into proper submodule Repos
| (like haddock.git) and figure out how to get the sync-all
| convenience-tooling a bit more submodule friendly...
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Fix linked list manipulation code (buggy on consecutive deletion) (e3938f3)
Thanks Edward. Austin, can you cherry-pick this for 7.8.3 please?
Cheers,
Simon
On 13/04/2014 07:37, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/ghc
On branch : master
Link :
http://ghc.haskell.org/trac/ghc/changeset/e3938f3adac0093b23694fd347774244ce121478/ghc
---
commit e3938f3adac0093b23694fd347774244ce121478
Author: Edward Z. Yang
Date: Sat Apr 12 23:02:13 2014 -0700
Fix linked list manipulation code (buggy on consecutive deletion)
Signed-off-by: Edward Z. Yang
---
e3938f3adac0093b23694fd347774244ce121478
rts/CheckUnload.c |3 ++-
rts/Linker.c |6 --
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/rts/CheckUnload.c b/rts/CheckUnload.c
index f1f454c..98f184b 100644
--- a/rts/CheckUnload.c
+++ b/rts/CheckUnload.c
@@ -298,7 +298,7 @@ void checkUnload (StgClosure *static_objects)
// marked as unreferenced can be physically unloaded, because we
// have no references to it.
prev = NULL;
- for (oc = unloaded_objects; oc; prev = oc, oc = next) {
+ for (oc = unloaded_objects; oc; oc = next) {
next = oc->next;
if (oc->referenced == 0) {
if (prev == NULL) {
@@ -312,6 +312,7 @@ void checkUnload (StgClosure *static_objects)
} else {
IF_DEBUG(linker, debugBelch("Object file still in use: %"
PATH_FMT "\n", oc->fileName));
+ prev = oc;
}
}
diff --git a/rts/Linker.c b/rts/Linker.c
index af26d74..ab235e9 100644
--- a/rts/Linker.c
+++ b/rts/Linker.c
@@ -3016,8 +3016,8 @@ unloadObj( pathchar *path )
IF_DEBUG(linker, debugBelch("unloadObj: %" PATH_FMT "\n", path));
prev = NULL;
-for (oc = objects; oc; prev = oc, oc = next) {
-next = oc->next;
+for (oc = objects; oc; oc = next) {
+next = oc->next; // oc might be freed
if (!pathcmp(oc->fileName,path)) {
@@ -3075,6 +3075,8 @@ unloadObj( pathchar *path )
/* This could be a member of an archive so continue
* unloading other members. */
unloadedAnyObj = HS_BOOL_TRUE;
+} else {
+prev = oc;
}
}
___
ghc-commits mailing list
ghc-comm...@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-commits
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.8.2 bugs and beyond
Hi Austin, Here are the iOS builds: https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8.2-device/ghc-7.8.2-arm-apple-ios.tar.bz2 SHA1 2160c203ed641e38e1306a722727105db97ea7d7 https://github.com/ghc-ios/ghc-ios-scripts/releases/download/7.8.2-simulator/ghc-7.8.2-i386-apple-ios.tar.bz2 SHA1 c855877d2b77a8c401da804373a3334e0dea43d4 & README https://github.com/ghc-ios/ghc-ios-scripts/blob/master/README.md On Fri, Apr 11, 2014 at 11:39 PM, Kazu Yamamoto wrote: > Helo, > > > The 7.8.2 source tarball is here. I actually have most of the binaries > > ready, but I forgot to send this in advance: > > > > http://www.haskell.org/ghc/dist/7.8.2/ > > > > Please build when you get a chance. I'll probably go ahead and > > announce shortly to get the bugfix into peoples hands, and we can > > incrementally add new tarballs. > > Now I can build yesod with GHC 7.8.2 on my Mac. Thanks. > > --Kazu > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: The build is broken (Solaris/x86, FreeBSD/{i386,amd64})
Hi, (probably) fixed by http://git.haskell.org/ghc.git/commitdiff/b4a820f97e48199a92f5ce7216731500f9a841c9 On 2014-04-14 at 09:15:42 +0200, Páli Gábor János wrote: [...] > utils/haddock/src/Haddock/Interface/Create.hs:367:44: > Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' > with '(a1, Located (HsBind id))' > Expected type: TyClDecl Name -> Bag (a1, Located (HsBind id)) > Actual type: TyClDecl Name -> LHsBinds Name > Relevant bindings include > defs :: [Located (HsDecl id)] > (bound at utils/haddock/src/Haddock/Interface/Create.hs:367:5) > In the second argument of '(.)', namely 'tcdMeths' > In the second argument of '(.)', namely 'bagToList . tcdMeths' > utils/haddock/src/Haddock/Interface/Create.hs:393:22: > Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' > with '(a0, Located (HsBind Name))' > Expected type: HsValBindsLR Name Name >-> [(a0, Located (HsBind Name))] > Actual type: HsValBindsLR Name Name -> [LHsBindLR Name Name] > In the first argument of '(.)', namely 'valbinds' > In the second argument of '(.)', namely 'valbinds . hs_valds' > gmake[1]: *** [utils/haddock/dist/build/Haddock/Interface/Create.dyn_o] Error > 1 > gmake: *** [all] Error 2 > > Please consult the details at > > http://haskell.inf.elte.hu/builders/solaris-x86-head/28/10.html ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
The build is broken (Solaris/x86, FreeBSD/{i386,amd64})
The failing command: "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O-hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen-optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package ghc-7.9.20140414 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/src/Haddock/Interface/Create.hs -o utils/haddock/dist/build/Haddock/Interface/Create.dyn_o utils/haddock/src/Haddock/Interface/Create.hs:367:44: Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' with '(a1, Located (HsBind id))' Expected type: TyClDecl Name -> Bag (a1, Located (HsBind id)) Actual type: TyClDecl Name -> LHsBinds Name Relevant bindings include defs :: [Located (HsDecl id)] (bound at utils/haddock/src/Haddock/Interface/Create.hs:367:5) In the second argument of '(.)', namely 'tcdMeths' In the second argument of '(.)', namely 'bagToList . tcdMeths' utils/haddock/src/Haddock/Interface/Create.hs:393:22: Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' with '(a0, Located (HsBind Name))' Expected type: HsValBindsLR Name Name -> [(a0, Located (HsBind Name))] Actual type: HsValBindsLR Name Name -> [LHsBindLR Name Name] In the first argument of '(.)', namely 'valbinds' In the second argument of '(.)', namely 'valbinds . hs_valds' gmake[1]: *** [utils/haddock/dist/build/Haddock/Interface/Create.dyn_o] Error 1 gmake: *** [all] Error 2 Please consult the details at http://haskell.inf.elte.hu/builders/solaris-x86-head/28/10.html ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
