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