[ghc-steering-committee] Amend or patterns (#522) to use p1 ; p2 (#609)

[Simon Peyton Jones]

>
> 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.
>

Breaking changes gated by a language extension are OK, right?  According to
our still-draft (GR1).  As Moritz says

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.
>

Simon M: are you arguing against, or just pointing out?

Simon

On Tue, 12 Sept 2023 at 08:27, Simon Marlow <marlowsd at gmail.com> wrote:

> 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.
>
> Cheers
> Simon
>
> On Sun, 10 Sept 2023 at 05:17, Moritz Angermann <
> moritz.angermann at gmail.com> wrote:
>
>> Joachim,
>>
>> 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?
>>
>> 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.
>>
>> Cheers,
>>  Moritz
>>
>> [1]:
>>
>> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst#costs-and-drawbacks
>>
>> On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner <
>> mail at joachim-breitner.de> wrote:
>>
>>> Hi,
>>>
>>> since this is guarded by an extension that doesn't even exist yet, no
>>> code is broken, is there?
>>>
>>> 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?
>>>
>>> (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.)
>>>
>>> So not opposed to an early warning, I just don't think it's strictly
>>> necessary for this change.
>>>
>>> Cheers,
>>> Joachim
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231003/10e838f0/attachment.html>