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

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/3a2487176e92b6972560ab1abdfa09a2b3eb4a49 )

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?

Trac metadata

Trac field	Value
Version	7.9
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import labels

mentioned in issue #9559 (closed)

mentioned in issue #9560 (closed)

Is this a GHC bug in 7.9 or in 7.8?

Neither really, this is an intentional change in behavior, see #8883 (closed). (Though I personally question whether it is worth breaking existing code for a rather intangible benefit.)

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 ?

closed

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

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedInvalid

added Pnormal label