- ghc-tickets - Haskell.org

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 16 Dec '14

16 Dec '14

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): I certainly plan to investigate each of the cases mentioned in the description but if you have any specific source files you know are likely to change between compilation, I ask that you post them here: I spent quite a lot of time trying to come up with some while I'd rather be fixing the problem instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:73> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints
by GHC 16 Dec '14

16 Dec '14

#2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm not against it. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2256#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9883: Make OverloadedLists more usable by splitting the class interface
by GHC 16 Dec '14

16 Dec '14

#9883: Make OverloadedLists more usable by splitting the class interface -------------------------------------+------------------------------------- Reporter: muesli4 | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: External Core | Version: 7.8.3 Keywords: overloaded lists, | Operating System: islist | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Moderate (less | None/Unknown than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- == Problem == While the OverloadedLists extension is very useful, it limits the types which can be used with it, by requesting too much. Assume you have a database specific DSEL which allows you to use list-like expressions in queries, it's easy to implement {{{fromList}}}, but we are unable to implement {{{toList}}} in a reasonable fashion without a backend and an existing connection. == Proposal == Modify the class interface in a way that does not require the instance to be ''listable''. {{{ class IsList l where type Item l fromList :: [Item l] -> l fromListN :: Int -> [Item l] -> l }}} We could then provide the pattern matching functionality on {{{IsList}}} instances with different approaches. === Another class === Just add another class which is used to provide the {{{toList}}} function, used on pattern matches. This is the easiest approach {{{ class AsList l where type Item l toList :: l -> [Item l] }}} Desugaring works as usual and it goes well with all structures. (The name is not the best though.) === Using Data.Foldable === The list pattern gets desugared using Data.Foldable: {{{ f :: (IsList l, Foldable l) => l -> l f [x, y, z] = [x, y] f l = l }}} gets something like: {{{ import Data.Foldable (toList) f :: (IsList l, Foldable l) => l -> l f (toList -> [x, y, z]) = fromList [x, y] f l = l }}} This approach does not go well with structures like {{{Data.Map}}}, because it expects the type constructor to take the ''element type'' as first argument, but we would like to have a tuple type. Maybe a wrapper could be provided, but I think it's not the way to go, as long as Data.Foldable does not use type families. == Drawbacks == Both approaches complicate the type of list expressions. This requires a bit more of typing, but it specifies exactly which functionality you need and one can simply drop the unused one, without creating dangerous dummy implementations: - {{{IsList}}} for overloaded list expressions - {{{AsList}}} or {{{Foldable}}} for pattern matching Most of the time OverloadedLists is used for convenience, so I don't expect the normal user to be really affected, library writers, specifically those who write some kind of DSEL, will have to be more precise, but get a more type-safe approach, which can not fail at runtime. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9883> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9888: Inconsistent type family resolution
by GHC 16 Dec '14

16 Dec '14

#9888: Inconsistent type family resolution -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is as small as I'm able to make the example. It uses the [http://hackage.haskell.org/package/singletons singletons] library. If I write my own `Map` type family, I can get the code to work. However, there seems to be a problem in GHC since I get seemingly conflicting information in GHCi. {{{#!hs {-# LANGUAGE TypeFamilies, TypeOperators, DataKinds, FlexibleContexts, UndecidableInstances #-} module Foo where import Data.Singletons.Prelude hiding (And) -- if every type in the list is equal, `CommonElt` returns the common type type family CommonElt xs where CommonElt (x ': xs) = EqResult (And (Map ((TyCon2 (==)) $ x) xs)) x type family a == b where a == a = 'True a == b = 'False type family And xs where And '[] = 'True And ('False ': xs) = 'False And ('True ': xs) = And xs -- converts a True result to a type type family EqResult b v where EqResult 'True r = r type R = CommonElt '[Int, Int] f :: R f = 3 }}} This code does not compile: {{{ Foo.hs:30:5: No instance for (Num (EqResult (And ((Int == Int) :$$$ '[])) Int)) arising from the literal ‘3’ In the expression: 3 In an equation for ‘f’: f = 3 Failed, modules loaded: none. }}} But if I comment out `f` and load the rest of the file in GHCi, I can easily see that `R ~ Int`: {{{ > :kind! R R :: * = Int }}} This seems suspicious to me because GHCi can resolve the type of `R`, but when code requiring `R` to be resolved is compiled (in GHCi or with GHC), I get the error above. I believe that `:kind!` is correctly resolving the type to `Int`, and that the type error is a bug. This is documented in more detail at [http://stackoverflow.com/questions/27490352/type-family-shenanigans-in- ghci this StackOverflow post]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9888> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints
by GHC 16 Dec '14

16 Dec '14

#2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): * Inference: We don't. Just like we don't infer higher-rank types (which, of course, are the same as implication constraints). If a user wants this feature, they have to ask for it. * Completeness: This is thornier. Here is how I see a problem arising: {{{ class C a class D a instance D Int needsD :: D a => a -> () implic :: (forall a. C a => D a) -> () implic = needsD (5 :: Int) }}} When typechecking `implic`, the local universal dictionary for `D a` will be used to provide a dictionary to `needsD`. This will then generate an unsatisfiable wanted `C Int`. But, of course, we could have just used the global instance `D Int` instead. An issue such as this one can't arise today (even with local dictionaries shadowing global ones) because local dictionaries never give rise to new wanteds. If you have a local dictionary, it's good to use. Given/Given interactions would be the same. If one implication-Given can be used in an interaction, it would be, giving rise to its antecedent Wanted constraints. This does get me a little worried about nondeterminism. But, I conjecture that if this interaction can give rise to nondeterminism, then it would be possible to exhibit the nondeterminism today, using overlapping instances. So, it all comes down to specifying completeness against what spec, and I'm saying that we could be complete against a spec where every local constraint shadows every overlapped global one. That is, when `(forall a. C a => D a)` is in scope, `instance D Int` is not. Will this be easy enough to use to make it practicable? There will be some surprises around it, but I think it's all quite easy to digest with a little guidance. (Certainly easier to understand than closed type families!) * Impredicativity: This, to me, is just like the story in kind `*`. `c` should be forbidden from unifying with an implication constraint. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2256#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9831: the 'impossible' happened : iselExpr64(powerpc)
by GHC 16 Dec '14

16 Dec '14

#9831: the 'impossible' happened : iselExpr64(powerpc) ----------------------------+---------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+---------------------------------------------- After working around the problem in #9828 I now run into this: {{{ "inplace/bin/ghc-stage1" -static -H64m -O -fasm -keep-tmp-files -Iincludes \ -Iincludes/dist -Iincludes/dist-derivedconstants/header \ -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build \ -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts \ -irts/dist/build -irts/dist/build/autogen -Irts/dist/build \ -Irts/dist/build/autogen -O2 -c rts/StgStartup.cmm \ -o rts/dist/build/StgStartup.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20141122 for powerpc-unknown-linux): iselExpr64(powerpc) I64[_c1::P32 + 64] - %MO_UU_Conv_W32_W64((Hp + 4) - I32[_c2::I32]) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9831> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #8024: Dynamic linking not working on PowerPC Linux.
by GHC 16 Dec '14

16 Dec '14

#8024: Dynamic linking not working on PowerPC Linux. ----------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: D560 | ----------------------------------------------+--------------------------- Changes (by slyfox): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8024#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints
by GHC 16 Dec '14

16 Dec '14

#2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I agree that much of this is not hard. And it's certainly useful. Indeed it is explicitly discussed in our Haskell Workshop 2000 paper [http://research.microsoft.com/en-us/um/people/simonpj/papers/derive.htm Derivable Type Classes]. The issues I see are: * Inference. If users can write such instances, they will probably expect them to be inferred. But that may wrongly defer a type error from a function to its call sites, by inferring an implication which is actually unsatisfiable. * Completeness. "Given" constraints interact with each other. How do "given" implications interact with simple "givens"? * Impredicativity. Can a constraint variable `c` be instantiated with one of these implications? Perhaps it's just a question of ruling that out. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2256#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9882: Kind mismatch with singleton [Nat]
by GHC 16 Dec '14

16 Dec '14

#9882: Kind mismatch with singleton [Nat] -------------------------------------+------------------------------------- Reporter: Roel van Dijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeOperators #-} import GHC.TypeLits ( Nat ) data Foo (n :: [Nat]) = Foo x :: Foo ('(:) 42 '[]) x = Foo y :: Foo (42 ': '[]) y = Foo z :: Foo [42] z = Foo }}} {{{ Expected kind ‘*’, but ‘42’ has kind ‘Nat’ In the type signature for ‘z’: z :: Foo [42] }}} I would expected z to be identical to both x and y. The error occurs in both GHCi and GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9882> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2`
by GHC 16 Dec '14

16 Dec '14

#9857: GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Compiling hackage:half-0.2 results in a GHC Panic: {{{ $ ghc --version && ghc --print-project-git-commit-id The Glorious Glasgow Haskell Compilation System, version 7.9.20141202 bf2d75417b5be7e8a79a26ee57a81e00682dabd4 $ cabal get half-0.2 && cd half-0.2/src/Numeric/ Unpacking to half-0.2/ $ ghc -Wall -O -fforce-recomp -c Half.hs ghc: panic! (the 'impossible' happened) (GHC version 7.9.20141202 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone lvl_s5yo To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 125160 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9857> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7