<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">+1<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Am 06.02.2019 um 09:35 schrieb Simon Marlow <<a href="mailto:marlowsd@gmail.com" class="">marlowsd@gmail.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">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 (<a href="https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-scc-parsing.rst" class="">https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-scc-parsing.rst</a>) but if that's too long then the summary is to adopt these principles:</div><div class=""><ol class=""><li class="">Annotations have the lowest precedence of all syntactic constructs.</li><li class="">Adding an annotation does not affect the structure or meaning of an
expression in ways other than adding an annotation to a subexpression.</li></ol><div class="">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.<br class=""></div><div class=""><br class=""></div><div class="">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").<br class=""></div></div></div><div dir="ltr" class=""><br class=""></div><div class="">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. </div><div dir="ltr" class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">So, I propose we accept this.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Simon</div><div class=""><br class=""></div><div dir="ltr" class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 3 Feb 2019 at 22:48, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" class="">mail@joachim-breitner.de</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Committee,<br class="">
<br class="">
this is your secretary speaking:<br class="">
<br class="">
Meaning-preserving parsing rules for SCC annotations<br class="">
has been proposed by Vladislav Zavialov:<br class="">
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/176" rel="noreferrer" target="_blank" class="">https://github.com/ghc-proposals/ghc-proposals/pull/176</a><br class="">
<a href="https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-scc-parsing.rst" rel="noreferrer" target="_blank" class="">https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-scc-parsing.rst</a><br class="">
<br class="">
I propose Simon Marlow as the shepherd (he already glimpsed at it, so<br class="">
hopefully already has an opinion.)<br class="">
<br class="">
Please reach consensus as described in<br class="">
<a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer" target="_blank" class="">https://github.com/ghc-proposals/ghc-proposals#committee-process</a><br class="">
I suggest you make a recommendation, in a new e-mail thread with the<br class="">
proposal number in the subject, about the decision, maybe point out<br class="">
debatable points, and assume that anyone who stays quiet agrees with<br class="">
you.<br class="">
<br class="">
Thanks,<br class="">
Joachim<br class="">
-- <br class="">
Joachim Breitner<br class="">
<a href="mailto:mail@joachim-breitner.de" target="_blank" class="">mail@joachim-breitner.de</a><br class="">
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank" class="">http://www.joachim-breitner.de/</a><br class="">
<br class="">
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div></div></div></div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></blockquote></div><br class=""></body></html>