language extensions ( Re: @-bindings broken in 6.0?)

[Christian Maeder]

> 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