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

[Simon Marlow]

On Tue, 3 Oct 2023 at 11:15, Simon Peyton Jones <simon.peytonjones 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.
>>
>
> 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?
>

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.

Cheers
Simon


>
> 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/dd08efa0/attachment.html>