Parser changes for supporting top-level SCC annotations
Ömer Sinan Ağacan
omeragacan at gmail.com
Mon May 30 19:14:48 UTC 2016
I'm trying to support SCCs at the top-level. The implementation should be
trivial except the parsing part turned out to be tricky. Since expressions can
appear at the top-level, after a {-# SCC ... #-} parser can't decide whether to
reduce the token in `sigdecl` to generate a `(LHsDecl (Sig (SCCSig ...)))` or to
keep shifting to parse an expression. As shifting is the default behavior when a
shift/reduce conflict happens, it's always trying to parse an expression, which
is always the wrong thing to do.
Does anyone have any ideas on how to handle this?
Motivation: Not having SCCs at the top level is becoming annoying real quick.
For simplest cases, it's possible to do this transformation:
f x y = ...
=>
f = {-# SCC f #-} \x y -> ...
However, it doesn't work when there's a `where` clause:
f x y = <t is in scope>
where t = ...
=>
f = {-# SCC f #-} \x y -> <t is out of scope>
where t = ...
Or when we have a "equation style" definition:
f (C1 ...) = ...
f (C2 ...) = ...
f (C3 ...) = ...
...
(usual solution is to rename `f` to `f'` and define a new `f` with a `SCC`)
More information about the ghc-devs
mailing list