What about just using a new pragma?
> {-# SCC_FUNCTION f "f_scc" #-}
> f True = ...
> f False = ...
The pragma takes the name of the function (a single identifier) and the name of
the SCC. If you wish both to have the same name, you can leave off the SCC name.
It seems worth it to me to introduce a new pragma here.
Richard
On May 30, 2016, at 3:14 PM, Ömer Sinan Ağacan <[email protected]> wrote:
> 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`)
> _______________________________________________
> ghc-devs mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
