GHC 6.6 GADT type unification vs GHC 6.8

Simon Peyton-Jones simonpj at
Tue Jul 29 04:07:58 EDT 2008

GHC 6.6 was a bit more generous than GHC 6.8, but erroneously so.   Specifically, GHC 6.8 and all subsequent versions require that when you pattern match on a value of GADT type,

*         the type of the scrutinee

*         the type of the result of the case

*         the types of any free variables used inside the case alternatives
are all completely known ("rigid" in GHC's terminology) at the case expression.

The easiest way to make a variable have a rigid type is to give it a type signature.

I don't expect to revert to GHC 6.6's behaviour because I don't know how to do (robust, complete) type inference for that.

I'll add these remarks to the user manual.


From: glasgow-haskell-users-bounces at [mailto:glasgow-haskell-users-bounces at] On Behalf Of Jason Dagit
Sent: 21 July 2008 20:44
To: glasgow-haskell-users at
Subject: GHC 6.6 GADT type unification vs GHC 6.8


I was wresting with the problem of converting our type witness code in darcs to work with ghc 6.8 and it occurred to me that someone has probably document the change somewhere.  In particular, I'm seeing this error message a lot, but 6.6 doesn't give this message:
    GADT pattern match in non-rigid context for `NilRL'
      Tell GHC HQ if you'd like this to unify the context

The main difference I have observed is that 6.6 infers types in case statements fully, but 6.8 seems to skip them and expects type signatures.  Sometimes I'm at a loss to figure out where to add the type signature to satisfy 6.8 and the process becomes tedious and time consuming.  I'm using 6.8.2 and I did see this thread:

What version of GHC do I need to see the improved diagnostics mentioned in that thread?

Will the GADT unification in 6.10 be compatible with 6.6?  If so, maybe I shouldn't convert the code to work for 6.8.  Also, can someone point me to a discussion of the difference or a paper about it?

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Glasgow-haskell-users mailing list