#2497: Weird scoping for tyvars in rules
----------------------+-----------------------------------------------------
Reporter: rl | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.8.3
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
----------------------+-----------------------------------------------------
Changes (by simonpj):
* difficulty: => Unknown
Comment:
Ah, there are a bunch of issues here. Two other closely related tickets
are
#2498 and #2213. I'll write some notes here to cover all three. I have
not executed any of the actions; I'm interested to know what others think
* RULES pragmas can't be parsed if the lexer isn't recognising 'forall'
as a keyword (you'd get parse errors immediately). So the lexer only
recognises RULES as a pragma if the lexer's explicitForallBit is on.
Currently that bit is switched on by the extensions `ScopedTypeVariables`,
`PolymorphicComponents`, `ExistentialQuantification`, `Rank2Types`, and
`RankNTypes`.
* If one of these flags isn't on, the lexer pretends not to recongise
the RULES pragma, which in turn gives an "unrecognised pragma" error in
the HEAD. That seems wrong, regardless of flags: it's a perfectly good
pragma.
* '''ACTION 1''': We should have a language extension `-XRewriteRules`
that makes the lexer recognise RULES pragmas. If `-XRewriteRules` is not
on, they should be silently ignored as comments.
* '''ACTION 2''': The `-XRewriteRules` extension should enable 'forall'
as a keyword (the explicitForAllBit).
* In a RULE, the 'forall' binds only *term*-variables. You can't say
`RULES "foo" forall a (x::a). <blah>`. There's no reason in principle why
not, but we'd need syntax to distinguish term from type variables, so I
don't propose to change this.
* So type variables are brought into scope much as they are in a pattern
match, such as `(\(x::a) -> blah)`. At the moment, you have to specify
*both* `-XPatternSignatures` to allow such a type signature in a pattern
at all; '''and''' `-XScopedTypeVariables` to allow the type variable to
have scope
This is a bit confusing, but it does make sense to have
`-XPatternSignatures` without `-XScopedTypeVariables`; you migh say
`(\(x::Int)-> blah)` for example.
'''ACTION 3''': still, I propose that `-XScopedTypeVariables` *implies*
`-XPatternSignatures`.
* Currently if you use `-XPatternSignatures` without
`-XScopedTypeVariables` for `(\(x::a) -> blah)` you get
{{{
T2497.hs:3:28: Not in scope: type variable `a'
}}}
And you can see why now!
* RULES always allow signatures on the forall'd binders; you don't need
-XPatternSignatures (and I think it'd be pedantic to require it). So now
you can see why you get the scope error. Possible alternatives to the
status quo
* `-XRewriteRules` implies `-XScopedTypeVariables`, in the entire
module
* We unconditionally but locally enable `-XScopedTypeVariables` in a
rewrite rule. In some ways this would be consistent with the way that
RULES allow signatures without a flag
'''ACTION 4''': Opinions?
* The flag `-frewrite-rules` is actually an *optimisation* flag. If
it's off, the Simplifier doesn't apply any rules at all. It's implied by
-O.
'''ACTION 5''': it looka s bit too much like a language flag. I wonder
about renaming it to `-fenable-rewrite-rules` or `-fuse-rewrite-rules`
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2497#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
