<div dir="ltr"><div>I'm in favour of acceptance. The possibility to use layout, like in Chris's example in his recommendation email, is especially convincing to me: in Ocaml, many or patterns are layed out that way (despite the fact that Ocaml's grammar is insensitive to layout). Something like</div><div><br></div><div>foo = function</div><div> | A -> a</div><div> | B</div><div> | C -> b</div><div> | D -> d</div><div><br></div><div>It feels very natural there, it'll feel natural in Haskell too.</div><div><br></div><div>---</div><div><br></div><div>Regarding backward compatibility, my understanding is the same as Moritz: in its current text, pattern synonyms are parsed differently regardless of whether -XOrPattern is turned on. This looks like a rather minor breakage, so I'm happy to follow the rest of the committee on the stance to take regarding this breakage. However, I would point out that this change to the pattern synonym syntax doesn't appear to be motivated in the text, at least it's not immediately apparent to me why it was deemed necessary. Maybe I missed something?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 10 Sept 2023 at 07:26, Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com" target="_blank">moritz.angermann@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Joachim,</div><div dir="auto"><br></div><div dir="auto">I have absolutely no issue with new extensions rejecting code that compiles fine without them. My only objections is to GHC not accepting code it accepted before without a deprecation period in between.</div><div dir="auto"><br></div><div dir="auto">The only thing I object is GHC X compiling code just fine and GHC X+1 rejecting the exact same code.</div><div dir="auto"><br></div><div dir="auto">Imo I think only X+3 should be permitted to reject code that X compiled. And X+1 and X+2 should warn about the upcoming change to syntax.</div><div dir="auto"><br></div><div dir="auto">But I can compromise on X+2, with X+1 having deprecation warnings.</div><div dir="auto"><br></div><div dir="auto">What I am unwilling to permit is X+1 rejecting code that X accepted without warning. That is sudden breakage of code.</div><div dir="auto"><br></div><div dir="auto">This form of basic absolutely minimal backwards compatibility is absolutely essential for proper regression testing of the compiler. If I can not trivially swap out the compiler in a working codebase, we have no hope for proper regression testing or quality control.</div><div dir="auto"><br></div><div dir="auto">Best,</div><div dir="auto"> Moritz</div><div dir="auto"><br></div><div dir="auto">On Sun, 10 Sep 2023 at 12:47 PM, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div style="font-family:sans-serif">
</div>
<div>
<div dir="ltr" style="font-family:sans-serif">
<p style="font-family:sans-serif">09.09.2023 21:17:01 Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com" style="font-family:sans-serif" target="_blank">moritz.angermann@gmail.com</a>>:</p>
</div></div></div><div><div>
<blockquote style="margin:0px;border-left:3px solid rgb(204,204,204);padding-left:10px">
<div dir="auto">
Joachim,
</div>
<div dir="auto">
<br>
</div>
<div dir="auto">
My understand if the cost and drawbacks section[1], is that existing code breaks even without explicitly enabling the extension. If this is indeed not the case it should be called our explicitly in the section that breakage requires the extension to be enabled. Also an explanation why the patsyn test cases fail. Do we automatically enable that extension in the testsuite? Where does the regression come from?
</div>
<div dir="auto">
<br>
</div>
<div dir="auto">
Maybe I’m misreading that section and it just needs to be clarified that there is _no breakage without **explixitly** enabling the extension_ to existing code.
</div>
<div dir="auto">
<br>
</div>
<div dir="auto">
Cheers,
</div>
<div dir="auto">
Moritz
</div>
<div dir="auto">
<br>
</div>
<div dir="auto">
[1]:
<div>
<a href="https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst#costs-and-drawbacks" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst#costs-and-drawbacks</a>
</div>
</div>
<div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">
On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div style="font-family:sans-serif"><span dir="ltr" style="margin-top:0px;font-family:sans-serif;margin-bottom:0px">Hi,</span> <br> <br> <span dir="ltr" style="margin-top:0px;font-family:sans-serif;margin-bottom:0px">since this is guarded by an extension that doesn't even exist yet, no code is broken, is there?</span> <br> <br> <span dir="ltr" style="margin-top:0px;font-family:sans-serif;margin-bottom:0px">I also don't expect this to be enabled in the future without coinciding with an intentional action by the developers - enabling this extension or switching to a future language edition that has this enabled by default (should that ever exist). Is it not sufficient if they are _then_ bothered with this change?</span> <br> <br> <span dir="ltr" style="margin-top:0px;font-family:sans-serif;margin-bottom:0px">(That said, we could say that a unparenthized type annotation on a pattern synonym is simply confusing, and thus use a warning to nudge the developers to add the parentheses now.)</span> <br> <br> <span dir="ltr" style="margin-top:0px;font-family:sans-serif;margin-bottom:0px">So not opposed to an early warning, I just don't think it's strictly necessary for this change.</span> <br> <br> <span dir="ltr" style="margin-top:0px;font-family:sans-serif;margin-bottom:0px">Cheers,</span> <br> <span dir="ltr" style="margin-top:0px;font-family:sans-serif;margin-bottom:0px">Joachim </span> <br> <br>
</div>
</div> _______________________________________________<br> ghc-steering-committee mailing list<br> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote>
</div>
</div>
</blockquote>
</div></div><div><div></div> <span dir="ltr" style="margin-top:0px;margin-bottom:0px">Hi,</span> <br> <br> <span dir="ltr" style="margin-top:0px;margin-bottom:0px">I would assume that all this only applies under {- LANGUAGE Or Patterns -}, but it seems it's not actually explicitly stated as such.</span> <br> <br> <span dir="ltr" style="margin-top:0px;margin-bottom:0px">I understand the breakage section as “what code needs to be changed when you enable the extension”. But maybe that's too optimistic?</span> <br> <br> <span dir="ltr" style="margin-top:0px;margin-bottom:0px">Chris, can you get clarification on this?</span> <br> <br> <span dir="ltr" style="margin-top:0px;margin-bottom:0px">Mortiz, assuming all changes are guarded by an extension, do you agree that no early warning would be necessary?</span> <br> <br> <span dir="ltr" style="margin-top:0px;margin-bottom:0px">Cheers,</span> <br> <span dir="ltr" style="margin-top:0px;margin-bottom:0px">Joachim </span> <br>
</div>
</blockquote></div></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div>