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 possible to do it by having multiple entry points to the parser, sharing as much of the grammar as possible, but I haven't tried (it sounds a bit sledgehammerish). We can often do optional syntax by parameterising the lexer, however: in fact there are already four switches that affect the syntax (-fglasgow-exts, -farrows, -fwith, -fffi). These generally work by turning on or off certain keywords (eg. -fffi turns on the 'foreign' keyword), which is usually all you need. Bottom line: yes in most cases you can give separate extensions their own flags. We're starting to move in that direction for new extensions, and if we get around to it we might separate some of the existing extensions. Cheers, Simon
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
participants (2)
-
Christian Maeder -
Simon Marlow