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

[Moritz Angermann]

Joachim,

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.

The only thing I object is GHC X compiling code just fine and GHC X+1
rejecting the exact same code.

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.

But I can compromise on X+2, with X+1 having deprecation warnings.

What I am unwilling to permit is X+1 rejecting code that X accepted without
warning. That is sudden breakage of code.

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.

Best,
 Moritz

On Sun, 10 Sep 2023 at 12:47 PM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> 09.09.2023 21:17:01 Moritz Angermann <moritz.angermann at gmail.com>:
>
> 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
>>
> Hi,
>
> I would assume that all this only applies under {- LANGUAGE Or Patterns
> -}, but it seems it's not actually explicitly stated as such.
>
> I understand the breakage section as “what code needs to be changed when
> you enable the extension”. But maybe that's too optimistic?
>
> Chris, can you get clarification on this?
>
> Mortiz, assuming all changes are guarded by an extension, do you agree
> that no early warning would be necessary?
>
> Cheers,
> Joachim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230910/535732ca/attachment-0001.html>