Parser changes for supporting top-level SCC annotations

[Simon Peyton Jones]

Terrific! 

Is there a ticket?  A wiki page with a specification?

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ömer
|  Sinan Agacan
|  Sent: 19 July 2016 10:04
|  To: ghc-devs <ghc-devs at haskell.org>
|  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 <omeragacan at gmail.com>:
|  > 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 <eir at cis.upenn.edu>:
|  >> 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
|  <omeragacan at gmail.com> 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 at 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 at 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