Opened 5 years ago

Closed 5 years ago

#9558 closed bug (invalid)

"Illegal equational constraint" that might not be the users fault

Reported by: rrnewton Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.9
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


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-
Building statistics-
Preprocessing library statistics-
[ 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 )

    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: )

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?

Change History (3)

comment:1 Changed 5 years ago 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.)

comment:2 Changed 5 years ago 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)


TypeFam a (~) b

vs (TypeFam a) ~ b ?

comment:3 Changed 5 years ago by simonpj

Resolution: invalid
Status: newclosed

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.


Note: See TracTickets for help on using tickets.