October 2016 - ghc-tickets

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 25 Oct '16

25 Oct '16

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, the comparison to `-XDatatypeContexts` is definitely a compelling argument for the current behavior. I'll quit my job as devil's advocate, then. In that case, that cements my opinion that associated data family instances should be totally unrelated to the instance context of the parent instance, and moreover, that the bug is really just a duplicate of #11008 in disguise, as the fix for this issue would be improving GHC's ability to infer exotic constraints. Should we close it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 25 Oct '16

25 Oct '16

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I would expect it to type check, because an associated family instance is sugar for an ordinary data family instance and I can't understand what it would mean to put a constraint on such an instance (or why I would want to; it feels like the old datatype contexts). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 25 Oct '16

25 Oct '16

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): What I mean is: if you had this code (using the example in comment:10): {{{#!hs c' :: [a] -> [a] -> Bool c' = c }}} then it would fail to typecheck, as there's no `Eq a` constraint, as mandated by the context in `instance Eq a => C [a]`. What I am asking is simply: should this `Eq a` constraint also be required for the associated family instances as well? That is, should this typecheck, even though it has no `Eq a` constraint? {{{#!hs dlist :: D [a] dlist = DList [] }}} (Currently, it //does// typecheck.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 25 Oct '16

25 Oct '16

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Can data family (or type family) instances even have contexts? What is that supposed to mean? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 25 Oct '16

25 Oct '16

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I would also be inclined to say "use the standalone route", for the reason that I don't see any reason why the `deriving` clause would infer `Eq (Associated a)` given the current state of things. I was merely imagining a hypothetical scenario in which data family instances //would// reasonable infer such a constraint when deriving instances. If data family instances were more tightly intermingled with their parent instances in terms of instance contexts, I could envision this being the case. P.S. Do you know why GHC decides `DList [] :: D [a]` instead of `DList [] :: Eq a => D [a]`? That is, why GHC chose to make associated data family instance contexts separate from their parent instances' contexts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12762: ASSERT failures on HEAD following typechecker refactoring
by GHC 25 Oct '16

25 Oct '16

#12762: ASSERT failures on HEAD following typechecker refactoring -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Erik says {{{ I suspect these commits 3f5673f34a2f761423027bf46f64f7499708725f may be responsible for 11 test failures: Unexpected results from: TEST="T9857 T12007 T9732 T9783 T9867 unboxed-wrapper-naked match-unboxed num T12698 T4439 unboxed-wrapper" SUMMARY for test run started at Sun Oct 23 16:56:26 2016 AEDT 0:00:02 spent to go through 11 total tests, which gave rise to 47 test cases, of which 36 were skipped 0 had missing libraries 0 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 11 unexpected failures 0 unexpected stat failures Unexpected failures: deSugar/should_compile/T4439.run T4439 [exit code non-0] (normal) ghci/scripts/T12007.run T12007 [bad stderr] (ghci) patsyn/should_compile/num.run num [exit code non-0] (normal) patsyn/should_compile/T9732.run T9732 [exit code non-0] (normal) patsyn/should_compile/T9857.run T9857 [exit code non-0] (normal) patsyn/should_compile/T9867.run T9867 [exit code non-0] (normal) patsyn/should_compile/T12698.run T12698 [exit code non-0] (normal) patsyn/should_fail/unboxed-wrapper-naked.run unboxed-wrapper-naked [stderr mismatch] (normal) patsyn/should_run/T9783.run T9783 [exit code non-0] (normal) patsyn/should_run/match-unboxed.run match-unboxed [exit code non-0] (normal) patsyn/should_run/unboxed-wrapper.run unboxed-wrapper [exit code non-0] (normal) }}} SPJ says: indeed! Fixing now. I hadn't compiled the testsuite with DEBUG on, and doing so indeed shows up two lurking bugs! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12762> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12507: Can't deduce implicit parameter
by GHC 25 Oct '16

25 Oct '16

#12507: Can't deduce implicit parameter -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried running a [https://gist.github.com/llelf/6c01ded225877914f38a gist] {{{#!hs {-# LANGUAGE GADTs, ConstraintKinds, Rank2Types, ImplicitParams #-} data Rec fields where Rec :: fields => Rec fields infixr 1 ? (?) :: Rec fields -> (fields => r) -> r Rec ? e = e record :: Rec (?a :: Int, ?b :: String) record = Rec where ?a=42 ?b="hey" access :: Int access = record ? ?a }}} and got {{{ $ ghci -ignore-dot-ghci tCHB.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tCHB.hs, interpreted ) tCHB.hs:15:19: error: • Could not deduce: ?a::Int arising from a use of implicit parameter ‘?a’ from the context: (?a::Int, ?b::String) bound by a type expected by the context: (?a::Int, ?b::String) => Int at tCHB.hs:15:10-20 • In the second argument of ‘(?)’, namely ‘?a’ In the expression: record ? ?a In an equation for ‘access’: access = record ? ?a Failed, modules loaded: none. Prelude> }}} I would certainly expect the context `(?a::Int, ?b::String)` to imply `?a::Int`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12507> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12174: Recursive use of type-in-type results in infinite loop
by GHC 25 Oct '16

25 Oct '16

#12174: Recursive use of type-in-type results in infinite loop -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Typechecking this module results in an infinite loop: {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeInType #-} module X where data V a data T = forall (a :: S). MkT (V a) data S = forall (a :: T). MkS (V a) }}} There's a mutually recursive reference so it should be rejected but maybe the check is not happening early enough (or the existing check is only for self-reference.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12174> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12081: TypeInType Compile-time Panic
by GHC 25 Oct '16

25 Oct '16

#12081: TypeInType Compile-time Panic -------------------------------------+------------------------------------- Reporter: MichaelK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been playing around with GHC 8.0.1-rc4 release and got a panic from the following (stripped down) code: {{{#!hs {-# LANGUAGE TypeInType #-} data Nat = Z | S Nat class C (n :: Nat) where type T n :: Nat f :: (a :: T n) }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160421 for x86_64-apple-darwin): isInjectiveTyCon sees a TcTyCon T }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12081> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12386: Infinite loop when showing type family error
by GHC 25 Oct '16

25 Oct '16

#12386: Infinite loop when showing type family error -------------------------------------+------------------------------------- Reporter: elliottt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When attempting to load this code in ghci with ghc-8.0.1, I get an infinite loop while it attempts to display the error: {{{ {-# LANGUAGE TypeFamilies #-} class C a where type family F a t :: * type family T a :: * type T a = F a }}} {{{ catbug :: ~/Scratch/ast-experiment » ghci test.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/trevor/.ghci [1 of 1] Compiling Main ( test.hs, interpreted ) test.hs:7:14: error: }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12386> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9