[GHC] #9558: "Illegal equational constraint" that might not be the users fault
#9558: "Illegal equational constraint" that might not be the users fault -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: 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: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If you try the latest cabal head and GHC together as of 2014.09.04, and then you try to install statistics, you'll see an error like the following, which does not occur in GHC 7.8.3: {{{ cabal-1.21 install -w ghc-7.9.20140904 Resolving dependencies... Configuring statistics-0.13.2.1... Building statistics-0.13.2.1... Preprocessing library statistics-0.13.2.1... [ 1 of 46] Compiling Statistics.Test.Internal ( Statistics/Test/Internal.hs, dist/build/Statistics/Test/Internal.o ) [ 2 of 46] Compiling Statistics.Test.Types ( Statistics/Test/Types.hs, dist/build/Statistics/Test/Types.o ) [ 3 of 46] Compiling Statistics.Internal ( Statistics/Internal.hs, dist/build/Statistics/Internal.o ) [ 4 of 46] Compiling Statistics.Transform ( Statistics/Transform.hs, dist/build/Statistics/Transform.o ) Statistics/Transform.hs:113:3: Illegal equational constraint Control.Monad.Primitive.PrimState m ~ s (Use GADTs or TypeFamilies to permit this) When checking that ‘bitReverse’ has the inferred type bitReverse :: forall (m :: * -> *) b. (Control.Monad.Primitive.PrimMonad m, Control.Monad.Primitive.PrimState m ~ s) => Int -> Int -> m b In an equation for ‘mfft’: }}} (Indeed, adding the GADTs language pragma makes the type checker happy, as in the commit here: https://github.com/rrnewton/criterion/commit/3a2487176e92b6972560ab1abdfa09a... ) Hmm, well, the source code in this case did not explicitly add the "~ s" constraint, the inference cooked it up. Is this a GHC bug in 7.9 or in 7.8? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9558 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9558: "Illegal equational constraint" that might not be the users fault -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton):
Is this a GHC bug in 7.9 or in 7.8?
Neither really, this is an intentional change in behavior, see #8883. (Though I personally question whether it is worth breaking existing code for a rather intangible benefit.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9558#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9558: "Illegal equational constraint" that might not be the users fault -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): could this just be an issue of precedence in the parser? (I don't have a current build of head right now so i cant try till later) ie TypeFam a (~) b vs (TypeFam a) ~ b ? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9558#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#9558: "Illegal equational constraint" that might not be the users fault -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Reid is right. Is the change a good design choice? In general I think "yes". The language extensions are meant to say whether or not you are using a language extension in a module; and if you need an extension to write down the type of a function you are defining I think that yes, you are using the extension. But if it causes major backward-compatibility pain, that might have outweighed it (if we'd known). But now 7.8 is out. I'll close this as invalid (since it is by-design), but if anyone feels strongly we should actually change back (in 7.10) to the previous design (where GHC would infer a type that you could not write in a type signature without adding more flags), then please open a new ticket to say so and why. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9558#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC