[ghc-steering-committee] #176: SCC Parsing, recommendation: accept

[Simon Peyton Jones]

I’m supportive.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 06 February 2019 08:36
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] #176: SCC Parsing, recommendation: accept

Proposal #176 is a small change to the syntax to make the parsing of certain pragmas (SCC, GENERATED, CORE) more principled and less likely to lead to confusion for users. The proposal itself has a nice motivation section that explains the problem (https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-scc-parsing.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fint-index%2Fghc-proposals%2Fblob%2Fscc-parsing%2Fproposals%2F0000-scc-parsing.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679271674&sdata=TJveWEMTpahWPnxeQ4m%2FMLn%2FG3jLvlEXtyDFBQAKCUA%3D&reserved=0>) but if that's too long then the summary is to adopt these principles:

  1.  Annotations have the lowest precedence of all syntactic constructs.
  2.  Adding an annotation does not affect the structure or meaning of an expression in ways other than adding an annotation to a subexpression.
and it turns out that doing that means that there are places where an SCC annotation should be illegal. Some of those places were illegal already, but not all - some places were SCC is currently legal have the effect of violating principle (2) above.

The change itself is to move a few productions in the grammar, making SCC annotations have the same precedence and associativity as the family of constructs including lambda, let, and do. That is, they have the lowest precedence and are right-associative, which is what we normally expect (the informal description is usually "extends as far to the right as possible").

A lot of the discussion has been around how to precisely specify and document the rule for users, and I'm satisfied that we can do this.

The only reason not to accept this would be that some existing code may fail to compile with the new grammar. However, it's likely to be rare and easy to fix, and within the bounds of the kinds of breaking change that we normally make in a major GHC release. Furthermore fixing the code to work with both old and new compilers doesn't require any conditional compilation.

So, I propose we accept this.

Cheers,
Simon


On Sun, 3 Feb 2019 at 22:48, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

this is your secretary speaking:

Meaning-preserving parsing rules for SCC annotations
has been proposed by Vladislav Zavialov:
https://github.com/ghc-proposals/ghc-proposals/pull/176<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F176&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679271674&sdata=SfuBj889NVTj4zh%2FNXU4NMErRH4vihXEgwcc95IkNPE%3D&reserved=0>
https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-scc-parsing.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fint-index%2Fghc-proposals%2Fblob%2Fscc-parsing%2Fproposals%2F0000-scc-parsing.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679281668&sdata=Pk3OCZvv4L%2BN57sFRF%2BZ%2BqoBReZ3QoR1O%2F2xi7abY8g%3D&reserved=0>

I propose Simon Marlow as the shepherd (he already glimpsed at it, so
hopefully already has an opinion.)

Please reach consensus as described in
https://github.com/ghc-proposals/ghc-proposals#committee-process<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679281668&sdata=bI75BzUzn%2BCiPb183kIOdZ3%2BX1PNWxItiXuNOONswSc%3D&reserved=0>
I suggest you make a recommendation, in a new e-mail thread with the
proposal number in the subject, about the decision, maybe point out
debatable points, and assume that anyone who stays quiet agrees with
you.

Thanks,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679291663&sdata=ST5c032JWNAMCoWhMVUryca02Mmg8Bnfd%2FgmXMCRoA0%3D&reserved=0>

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C789be33375494f9342ae08d68c0e227b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850389679291663&sdata=KZQCrGQeoWjKk6sV20IGWVPk%2BHzzEsruSJLdGasKtUo%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190206/757be3e7/attachment.html>