I think lumping all these extensions under one switch is the problem.
Yep, I agree. Would it be hard to split `-fglasgow-exts' up? I'd greatly appreciate a more fine-grained control here.
The only difficulty is that we don't have an easy way to parameterise the parser, since it's generated from a fixed grammar. It might be
I think, the parser should not be parameterized! Ideally, a language extension should provide a meaning to programs that are rejected without that extension. A program that can be compiled without extensions must go through (with the same meaning) with any or all extensions switched on. This wasn't the case for "[t|" that could start a list comprehension or a template haskell bit. Therefore the syntax for template haskell should change, since it is less convincing to forbid "[t|" as comprehension. Usually combining reserved keywords or keyops is a good way to extend the syntax without loss. So "[: ... :]" (parallel arrays) "[| ... |]" (th expression quotations) are ok. And maybe "[{ ... }]", "[@ ... @]", "[~ ... ~]", "[= ... =]", (and similar things with curly braces) are further alternatives. New keyords (like "foreign") should be forbidden for the Standard (post mortem)! ("forall" and "exists" should be illegal as type variables in Haskell98.) I don't know what the new arrows add Is it "mdo", "mreturn"? Why not "\do", "\return" (or "let do", "let return" or "|do|", "|return|")? Otherwise ghc simply supports a disjoint set of languages. Christian P.S. I agree however to have several switches (to be analysed after parsing) -ffunctional-dependencies -fhigher-rank-polymorphism