require -XGADTs in order to pattern-match GADTs

[guest]

Without -XGADTs, pattern-matching GADTs causes weird typechecking problems (due to the lack of implied -XRelaxedPolyRec), see this thread  http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/16064 , and some history in bug #2004

I propose that pattern-matching against any constructor that uses sufficient GADT features that it's particularly confused without -XRelaxedPolyRec, should require -XGADTs

(I don't understand the issue well enough to know if what I'm saying makes sense. I guess ordinary data and mere existentials don't need it, even when defined with GADT syntax...?)

Alternately we could just require -XRelaxedPolyRec, but that seems even more confusing (and it wouldn't help make code portable to other compilers, as GADTs are definitely being used). Or if Haskell-prime ever comes around and makes -XRelaxedPolyRec default (is it planning to?), then the issue might be moot. I don't think the argument (against requiring -XGADTs) by parallel to -XOverlappingInstances is particularly strong... -XOverlappingInstances has an implicit effect on a module's class definitions... also I don't necessarily agree with that we made that decision for existing flags either :-)

--Isaac Dupree

[Dominic]

I would vote for requiring the -XGADTs flag if you are using GADTs not merely defining them. Either that or a better suggestion on the error message (although this might be annoying for real "GADT pattern match in non-rigid context" errors).

[int-e]

I also support requiring -XGADTs for pattern matching against GADT constructors - and I'd include the case where the GADT is really a plain data type or existential, because that makes the behaviour much easier to explain: "You used GADT syntax to define it, you need -XGADTs to pattern match against it." Merely mentioning GADTs in type signatures should work without the extension.

[simonpj]

Done

Wed Feb  4 15:09:19 GMT 2009  simonpj@microsoft.com
  * Check -XGADTs in (a) type family decls (b) pattern matches

Don't merge to the branch; it's a small change in behaviour.

Simon