Terrific! Is there a ticket? A wiki page with a specification?
Simon | -----Original Message----- | From: ghc-devs [mailto:[email protected]] On Behalf Of Ömer | Sinan Agacan | Sent: 19 July 2016 10:04 | To: ghc-devs <[email protected]> | 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 <[email protected]>: | > 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 <[email protected]>: | >> 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] | >>> | 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 | [email protected] | 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 _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
