December 2014 - ghc-tickets

[GHC] #9226: Internal error when using equality constraint in pattern synonyms
by GHC 17 Dec '14

17 Dec '14

#9226: Internal error when using equality constraint in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.8.2 Keywords: renamer, pattern | Operating System: Linux synonyms, GADTs | Type of failure: GHC rejects Architecture: x86 | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- While going through [http://www.andres-loeh.de/dgp2005.pdf Extensible datatypes] I had the following code: {{{ {-# LANGUAGE GADTs, PatternSynonyms, ScopedTypeVariables, Rank2Types #-} data Rep a where RUnit :: Rep () RInt :: Rep Int RChar :: Rep Char REither :: Rep a -> Rep b -> Rep (Either a b) RPair :: Rep a -> Rep b -> Rep (a, b) foo :: (Rep a, a) -> Bool foo (RUnit, ()) = True }}} And I wanted to make a pattern synonyms matching `(RUnit, ())` in `foo`, my initial attempt was: {{{ pattern PUnit1 = (RUnit, ()) }}} gives the error (`punit1.log`) while writing {{{ pattern PUnit2 = (RUnit, ()) :: (Rep (), ()) }}} compiles but can't be used in `foo`. Trying: {{{ pattern PUnit3 = (RUnit, ()) :: (a ~ ()) => (Rep a, a) }}} gives a ''GHC internal error'' (`punit3.log`). I tried various other patterns such as: {{{ pattern PUnit4 <- (RUnit, ()) pattern PUnit5 <- (RUnit, ()) :: (Rep (), ()) pattern PUnit6 <- (RUnit, ()) :: (a ~ ()) => (Rep a, a) pattern PUnit7 = (RUnit, ()) :: forall a. (a ~ ()) => (Rep a, a) pattern PUnit8 <- (RUnit, ()) :: forall a. (a ~ ()) => (Rep a, a) ... }}} None of which work. The final goal was to rewrite: {{{ eq :: Rep a -> a -> a -> Bool eq rep a b = case (rep, a, b) of (RUnit, (), ()) -> True (RInt, n1, n2) -> n1 == n2 (RChar, c1, c2) -> c1 == c2 (REither l r, Left a, Left b) -> eq l a b (REither l r, Right a, Right b) -> eq r a b (REither{}, _, _) -> False (RPair l r, (a1, a2), (b1, b2)) -> eq l a1 b1 && eq r a2 b2 }}} as something like {{{ pattern PUnit = (RUnit, ()) -- (a ~ ()) => (Rep a, a) pattern PInt n = (RInt, n) -- (a ~ Int) => (Rep a, a) -- ... eq :: Rep a -> a -> a -> Bool eq rep a b = case ((rep, a), (rep, b)) of (PUnit, PUnit) -> True (PInt n1, PInt n2) -> n1 == n2 (PChar c1, PChar c2) -> c1 == c2 (PLeft l l1, PLeft l l2) -> eq l l1 l2 (PRight r r1, PRight r r2) -> eq r r1 r2 ((REither{}, _), _) -> False (PFst l (a1, b1), PSnd r (a2, b2)) -> eq l a1 b1 && eq r a2 b2 }}} where one can avoid pattern matching against the `Rep` constructor directly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9226> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types
by GHC 17 Dec '14

17 Dec '14

#9819: Create typesafe method of obtaining dictionary types from class definitions, and constraint objects from dictionary types -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Say I have a class like the following: {{{#!hs class IntLike a where fromInt :: Int -> a toInt :: a -> Int }}} There should be a typesafe, principled way to get the dictionary type created from buildClass in compiler/iface/BuildTyCl.lhs like such (in this hypothetical, using a type family: {{{#!hs plusN :: (IntLike a) => Int -> Dictionary (IntLike a) }}} It would be nice if the type family was injective, if it was implemented in such a way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9819> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

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 15 Dec '14

15 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 15 Dec '14

15 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 15 Dec '14

15 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