[GHC] #12652: Type checker no longer accepting code using function composition and rank-n types
#12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- The following program (reduced from Cabal code that uses HasCallStack) typechecks in GHC 8.0, but not on HEAD: {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ImplicitParams #-} module Foo where type T a = (?x :: Int) => a type M a = T (IO a) f :: T (T a -> a) f x = x g :: Int -> M () g = undefined h :: Int -> M () -- h x = f (g x) -- works on HEAD h = f . g -- fails on HEAD, works on GHC 8.0 }}} It's possible that this is just fall out from the recent impredicativity changes but I just wanted to make sure that this was on purpose. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12652 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonpj (added) * milestone: => 8.2.1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12652#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => simonpj @@ -4,1 +4,1 @@ - {{{ + {{{#!hs New description: The following program (reduced from Cabal code that uses HasCallStack) typechecks in GHC 8.0, but not on HEAD: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ImplicitParams #-} module Foo where type T a = (?x :: Int) => a type M a = T (IO a) f :: T (T a -> a) f x = x g :: Int -> M () g = undefined h :: Int -> M () -- h x = f (g x) -- works on HEAD h = f . g -- fails on HEAD, works on GHC 8.0 }}} It's possible that this is just fall out from the recent impredicativity changes but I just wanted to make sure that this was on purpose. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12652#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | 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 ezyang): Confirmed that b612da667fe8fa5277fc78e972a86d4b35f98364 is the regressing commit. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12652#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | 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 goldfire): The new behavior looks correct to me. `g`'s type expands to `Int -> (?x :: Int) => IO ()`, and it's critical that the `(?x :: Int)` bit does not get instantiated for this to type-check. Accordingly, the type parameters to `(.)` would have to be qualified types for this to work, so I say this is an improvement in behavior. Of course, it might just be time to extend the `($)` hack to work with `(.)`, too. Until we do so, though, we should reject the original program. Simon, what do you think? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12652#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | 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 simonpj): Richard is right on all counts. This works {{{ h = (.) @(M ()) @(M ()) @Int f g }}} recalling that `(.)` has type {{{ (.) :: forall b c a. (b -> c) -> (a -> b) -> a -> c -- Defined in ‘GHC.Base’ }}} It seems to me that if a special case for `($)` is justified, then having one for `(.)` as well would make sense. Perhaps using it should require `-XImpredicativeTypes` though? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12652#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | 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 goldfire): I'm all for making `(.)` special in the type-checker, but I don't think it should require `ImpredicativeTypes`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12652#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | 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): Agree with Richard. If we can impredicatively use `($)` without `ImpredicativeTypes`, I don't see why we'd need it for `(.)`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12652#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC