I managed to do this without introducing any new pragmas. I added a new production that doesn't look for SCC annotations, for top-level expressions. I then used it in decl_no_th and topdecl. I'm not sure if I broke anything though. I'll validate in slow mode now. Patch is here: http://phabricator.haskell.org/D2407 2016-06-01 12:55 GMT+00:00 Ömer Sinan Ağacan :

I was actually trying to avoid that, thinking that it'd be best if SCC uniformly worked for top-levels and expressions. But then this new form:

{-# SCC f "f_scc" #-}

Would only work for toplevel SCCs.. So maybe it's OK to introduce a new pragma here.

2016-06-01 8:13 GMT-04:00 Richard Eisenberg :

...

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 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 ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Terrific! Is there a ticket? A wiki page with a specification? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Ömer | Sinan Agacan | Sent: 19 July 2016 10:04 | To: ghc-devs | Subject: Re: Parser changes for supporting top-level SCC annotations | | I managed to do this without introducing any new pragmas. I added a | new production that doesn't look for SCC annotations, for top-level | expressions. I then used it in decl_no_th and topdecl. | | I'm not sure if I broke anything though. I'll validate in slow mode | now. | | Patch is here: | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fphabri | cator.haskell.org%2fD2407&data=01%7c01%7csimonpj%40064d.mgd.microsoft. | com%7c86268f4443a94ed46b1808d3afb3bf09%7c72f988bf86f141af91ab2d7cd011d | b47%7c1&sdata=jSC3m%2fCa3PJwhfmWbMzAawaN2hOE3oKnRbNdEb%2bUObo%3d | | 2016-06-01 12:55 GMT+00:00 Ömer Sinan Ağacan : | > I was actually trying to avoid that, thinking that it'd be best if | SCC | > uniformly worked for top-levels and expressions. But then this new | form: | > | > {-# SCC f "f_scc" #-} | > | > Would only work for toplevel SCCs.. So maybe it's OK to introduce a | > new pragma here. | > | > 2016-06-01 8:13 GMT-04:00 Richard Eisenberg : | >> 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 | 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 | >>> ghc-devs@haskell.org | >>> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail | >>> .haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01% | >>> | 7csimonpj%40064d.mgd.microsoft.com%7c86268f4443a94ed46b1808d3afb3bf0 | >>> | 9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=wd7%2fbeNxlmYHdZ8sfR% | >>> 2fXMl54PR0Pcg70huCmbow8M7Y%3d | >> | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c86268f4443a94ed | 46b1808d3afb3bf09%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=wd7%2fb | eNxlmYHdZ8sfR%2fXMl54PR0Pcg70huCmbow8M7Y%3d