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
