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