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

[Chris Dornan]

Exactly -- sorry, I should have picked this up at the start — my bad.

we are exploring non disruptive options in the thread thread on the PR




On 12 Sep 2023, at 08:26, 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/20230912/f917e0da/attachment.html>