<div dir="ltr"><div dir="ltr">On Tue, 3 Oct 2023 at 11:15, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@gmail.com</a>> wrote:</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 dir="ltr"><div style="font-family:tahoma,sans-serif">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Looks to me like it would be a breaking change even when the
extension is not enabled, because the grammar is not conditional on
extensions. The usual trick of using keywords to enable extensions
(because keywords can be conditionally enabled in the lexer) doesn't
work in this case.</div></blockquote><div><br></div><div>Breaking changes gated by a language extension are OK, right? According to our still-draft (GR1). As Moritz says</div><div><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">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></blockquote>
<div> </div><div>Simon M: are you arguing against, or just pointing out?</div></div></div></blockquote><div><br></div><div>To clarify: the proposal originally contained a breaking change that wasn't gated by the extension flag, but that's now been fixed. I don't have any objection to the proposal as it stands.</div><div><br></div><div>Cheers</div><div>Simon<br></div><div> </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="ltr"><div style="font-family:tahoma,sans-serif"><div><br></div><div>Simon<br></div>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 12 Sept 2023 at 08:27, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@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="ltr"><div>Looks to me like it would be a breaking change even when the extension is not enabled, because the grammar is not conditional on extensions. The usual trick of using keywords to enable extensions (because keywords can be conditionally enabled in the lexer) doesn't work in this case.</div><div><br></div><div>Cheers</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 10 Sept 2023 at 05:17, 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">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;margin-bottom:0px;font-family:sans-serif">Hi,</span> <br> <br> <span dir="ltr" style="margin-top:0px;margin-bottom:0px;font-family:sans-serif">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;margin-bottom:0px;font-family:sans-serif">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;margin-bottom:0px;font-family:sans-serif">(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;margin-bottom:0px;font-family:sans-serif">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;margin-bottom:0px;font-family:sans-serif">Cheers,</span> <br> <span dir="ltr" style="margin-top:0px;margin-bottom:0px;font-family:sans-serif">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>
_______________________________________________<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>
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>
</blockquote></div></div>