Amend or patterns (#522) to use p1 ; p2 (#609)

newer
GHC2024 timeline

older
#526: Applicative Comprehensions...

Chris Dornan

8 Sep 2023 8 Sep '23

10:57 a.m.

Proposal: Amend or patterns (#522) to use p1 ; p2 (#609) Author: Sebastian Graf, David Knothe Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49... Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609 Recommendation: Acceptance ## Summary This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns. The syntax of the old proposal, ```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (one of T2{}, T3{}) = Nothing ``` is replaced with ```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (T2{}; T3{}) = Nothing ``` or indeed ```haskell stringOfT :: T -> Maybe String stringOfT x = case x of T1 s -> Just s T2{} T3{} -> Nothing ``` (Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.) The authors have conducted polls to see what folks preferred, landing on this proposal. The adjustments to the Haskell grammar are really quite minimal requiring one extra production. ## Recommendation The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend that we accept it

Attachments:

attachment.html (text/html — 4.1 KB)

Show replies by date

Simon Peyton Jones

8 Sep 8 Sep

4:36 p.m.

I don't have a strong opinion here. The authors have done a pretty diligent job of exploring syntactic alternatives, and seeking feedback from the community. I'm quite content to accept this proposal. (We have already accepted the base or-pattern proposal, so that's not our subject for debate.) Simon On Fri, 8 Sept 2023 at 03:57, Chris Dornan wrote:

...

Proposal: Amend or patterns (#522) to use p1 ; p2 (#609) Author: Sebastian Graf, David Knothe Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49... Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609 Recommendation: Acceptance

## Summary

This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns.

The syntax of the old proposal,

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (one of T2{}, T3{}) = Nothing ```

is replaced with

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (T2{}; T3{}) = Nothing ```

or indeed

```haskell stringOfT :: T -> Maybe String stringOfT x = case x of T1 s -> Just s T2{} T3{} -> Nothing ```

(Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.)

The authors have conducted polls to see what folks preferred, landing on this proposal. The adjustments to the Haskell grammar are really quite minimal requiring one extra production.

## Recommendation

The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend that we accept it

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Vladislav Zavialov

5:47 p.m.

In favor On Fri, Sep 8, 2023 at 6:36 PM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

I don't have a strong opinion here. The authors have done a pretty diligent job of exploring syntactic alternatives, and seeking feedback from the community. I'm quite content to accept this proposal. (We have already accepted the base or-pattern proposal, so that's not our subject for debate.)

Simon

On Fri, 8 Sept 2023 at 03:57, Chris Dornan wrote:

...
Proposal: Amend or patterns (#522) to use p1 ; p2 (#609) Author: Sebastian Graf, David Knothe Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49... Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609 Recommendation: Acceptance

## Summary

This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns.

The syntax of the old proposal,

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (one of T2{}, T3{}) = Nothing ```

is replaced with

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (T2{}; T3{}) = Nothing ```

or indeed

```haskell stringOfT :: T -> Maybe String stringOfT x = case x of T1 s -> Just s T2{} T3{} -> Nothing ```

(Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.)

The authors have conducted polls to see what folks preferred, landing on this proposal. The adjustments to the Haskell grammar are really quite minimal requiring one extra production.

## Recommendation

The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend that we accept it

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Adam Gundry

7:58 p.m.

New subject: Amend or patterns (#522) to use p1 ; p2 (#609)

No objections from me. I tend not to pay too much attention to such syntactic niceties, but as the authors have gone to the trouble of surveying the community and implementing the proposal I see no reason not to accept their suggested syntax. I did notice that the PR drops Ömer's name from the authors list for #522, I'm not sure if that was intentional? Adam On 08/09/2023 18:47, Vladislav Zavialov wrote:

...

In favor

On Fri, Sep 8, 2023 at 6:36 PM Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

I don't have a strong opinion here. The authors have done a pretty diligent job of exploring syntactic alternatives, and seeking feedback from the community. I'm quite content to accept this proposal. (We have already accepted the base or-pattern proposal, so that's not our subject for debate.)

Simon

On Fri, 8 Sept 2023 at 03:57, Chris Dornan mailto:chris@chrisdornan.com> wrote:

Proposal: Amend or patterns (#522) to use p1 ; p2 (#609) Author: Sebastian Graf, David Knothe Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49... https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49... Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609 https://github.com/ghc-proposals/ghc-proposals/pull/609 Recommendation: Acceptance

## Summary

This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns.

The syntax of the old proposal,

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (one of T2{}, T3{}) = Nothing ```

is replaced with

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (T2{}; T3{}) = Nothing ```

or indeed

```haskell stringOfT :: T -> Maybe String stringOfT x = case x of T1 s -> Just s T2{} T3{} -> Nothing ```

(Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.)

The authors have conducted polls to see what folks preferred, landing on this proposal. The adjustments to the Haskell grammar are really quite minimal requiring one extra production.

## Recommendation

The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend that we accept it

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

Moritz Angermann

11:26 p.m.

As this breaks accepted code, I’d really like to see this on two steps. At least one GHC release that warns about pattern X <- 42 :: Int Being rejected by GHC going forward. Thus if we get a deprecation warning for that syntax with the guidance to put the rhs into parentheses, for at least one release prior to the breaking change, I have no objections. Moritz On Sat, 9 Sep 2023 at 3:58 AM, Adam Gundry wrote:

...

No objections from me. I tend not to pay too much attention to such syntactic niceties, but as the authors have gone to the trouble of surveying the community and implementing the proposal I see no reason not to accept their suggested syntax.

I did notice that the PR drops Ömer's name from the authors list for #522, I'm not sure if that was intentional?

Adam

On 08/09/2023 18:47, Vladislav Zavialov wrote:

...
In favor

On Fri, Sep 8, 2023 at 6:36 PM Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

I don't have a strong opinion here. The authors have done a pretty diligent job of exploring syntactic alternatives, and seeking feedback from the community. I'm quite content to accept this proposal. (We have already accepted the base or-pattern proposal, so that's not our subject for debate.)

Simon

On Fri, 8 Sept 2023 at 03:57, Chris Dornan mailto:chris@chrisdornan.com> wrote:

Proposal: Amend or patterns (#522) to use p1 ; p2 (#609) Author: Sebastian Graf, David Knothe Rendered proposal:

https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49... < https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49...

...
Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609 https://github.com/ghc-proposals/ghc-proposals/pull/609 Recommendation: Acceptance

## Summary

This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns.

The syntax of the old proposal,

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (one of T2{}, T3{}) = Nothing ```

is replaced with

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (T2{}; T3{}) = Nothing ```

or indeed

```haskell stringOfT :: T -> Maybe String stringOfT x = case x of T1 s -> Just s T2{} T3{} -> Nothing ```

(Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.)

The authors have conducted polls to see what folks preferred, landing on this proposal. The adjustments to the Haskell grammar are really quite minimal requiring one extra production.

## Recommendation

The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend that we accept it

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

10 Sep 10 Sep

4:04 a.m.

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

Moritz Angermann

4:16 a.m.

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/eb4b67c29282520b2c5c6a49... On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

4:47 a.m.

New subject: Amend or patterns (#522) to use p1 ; p2 (#609)

09.09.2023 21:17:01 Moritz Angermann :

...

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

On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner 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@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

Moritz Angermann

5:26 a.m.

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 wrote:

...

09.09.2023 21:17:01 Moritz Angermann :

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

On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner < mail@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@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

Arnaud Spiwack

5:11 p.m.

I'm in favour of acceptance. The possibility to use layout, like in Chris's example in his recommendation email, is especially convincing to me: in Ocaml, many or patterns are layed out that way (despite the fact that Ocaml's grammar is insensitive to layout). Something like foo = function | A -> a | B | C -> b | D -> d It feels very natural there, it'll feel natural in Haskell too. --- Regarding backward compatibility, my understanding is the same as Moritz: in its current text, pattern synonyms are parsed differently regardless of whether -XOrPattern is turned on. This looks like a rather minor breakage, so I'm happy to follow the rest of the committee on the stance to take regarding this breakage. However, I would point out that this change to the pattern synonym syntax doesn't appear to be motivated in the text, at least it's not immediately apparent to me why it was deemed necessary. Maybe I missed something? On Sun, 10 Sept 2023 at 07:26, Moritz Angermann wrote:

...

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@joachim-breitner.de> wrote:

...
09.09.2023 21:17:01 Moritz Angermann :

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

On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner < mail@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@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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

Chris Dornan

11 Sep 11 Sep

3:57 a.m.

New subject: Amend or patterns (#522) to use p1 ; p2 (#609)

With regards backwards compatibility I have asked the authors to clarify whether implementing the proposal is expected to break anything when the extension is not enabled. Chris

...

On 10 Sep 2023, at 18:11, Arnaud Spiwack wrote:

I'm in favour of acceptance. The possibility to use layout, like in Chris's example in his recommendation email, is especially convincing to me: in Ocaml, many or patterns are layed out that way (despite the fact that Ocaml's grammar is insensitive to layout). Something like

foo = function | A -> a | B | C -> b | D -> d

It feels very natural there, it'll feel natural in Haskell too.

---

Regarding backward compatibility, my understanding is the same as Moritz: in its current text, pattern synonyms are parsed differently regardless of whether -XOrPattern is turned on. This looks like a rather minor breakage, so I'm happy to follow the rest of the committee on the stance to take regarding this breakage. However, I would point out that this change to the pattern synonym syntax doesn't appear to be motivated in the text, at least it's not immediately apparent to me why it was deemed necessary. Maybe I missed something?

On Sun, 10 Sept 2023 at 07:26, Moritz Angermann mailto:moritz.angermann@gmail.com> wrote:

...
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 mailto:mail@joachim-breitner.de> wrote:

...
09.09.2023 21:17:01 Moritz Angermann mailto:moritz.angermann@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/eb4b67c29282520b2c5c6a49...

On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner mailto:mail@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@haskell.org mailto:ghc-steering-committee@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

ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com https://moduscreate.com/ and https://tweag.io https://tweag.io/. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Marlow

12 Sep 12 Sep

7:26 a.m.

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

On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner < mail@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Chris Dornan

9:31 a.m.

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

On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner < mail@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Peyton Jones

3 Oct 3 Oct

10:15 a.m.

...

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 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@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/eb4b67c29282520b2c5c6a49...

On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner < mail@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Marlow

3:36 p.m.

On Tue, 3 Oct 2023 at 11:15, Simon Peyton Jones 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 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@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/eb4b67c29282520b2c5c6a49...

On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner < mail@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Chris Dornan

29 Sep 29 Sep

11:47 a.m.

All, This proposal has now been revised to make it non-disruptive. That was the only issue of substance that surfaced in our discussion and I recommend that we accept this revised proposal. Chris

...

On 8 Sep 2023, at 11:57, Chris Dornan wrote:

Proposal: Amend or patterns (#522) to use p1 ; p2 (#609) Author: Sebastian Graf, David Knothe Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49... Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609 Recommendation: Acceptance

## Summary

This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns.

The syntax of the old proposal,

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (one of T2{}, T3{}) = Nothing ```

is replaced with

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (T2{}; T3{}) = Nothing ```

or indeed

```haskell stringOfT :: T -> Maybe String stringOfT x = case x of T1 s -> Just s T2{} T3{} -> Nothing ```

(Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.)

The authors have conducted polls to see what folks preferred, landing on this proposal. The adjustments to the Haskell grammar are really quite minimal requiring one extra production.

## Recommendation

The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend that we accept it

Moritz Angermann

12:46 p.m.

Sounds good to me. On Fri, 29 Sep 2023 at 7:47 PM, Chris Dornan wrote:

...

All,

This proposal has now been revised to make it non-disruptive.

That was the only issue of substance that surfaced in our discussion and I recommend that we accept this revised proposal.

Chris

On 8 Sep 2023, at 11:57, Chris Dornan wrote:

Proposal: Amend or patterns (#522) to use p1 ; p2 (#609) Author: Sebastian Graf, David Knothe Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49... Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609 Recommendation: Acceptance

## Summary

This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns.

The syntax of the old proposal,

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (one of T2{}, T3{}) = Nothing ```

is replaced with

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (T2{}; T3{}) = Nothing ```

or indeed

```haskell stringOfT :: T -> Maybe String stringOfT x = case x of T1 s -> Just s T2{} T3{} -> Nothing ```

(Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.)

The authors have conducted polls to see what folks preferred, landing on this proposal. The adjustments to the Haskell grammar are really quite minimal requiring one extra production.

## Recommendation

The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend that we accept it

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Eric Seidel

30 Sep 30 Sep

5:32 p.m.

I'm happy with this change. On Fri, Sep 29, 2023, at 08:46, Moritz Angermann wrote:

...

Sounds good to me.

On Fri, 29 Sep 2023 at 7:47 PM, Chris Dornan wrote:

...
All,

This proposal has now been revised to make it non-disruptive.

That was the only issue of substance that surfaced in our discussion and I recommend that we accept this revised proposal.

Chris

...
On 8 Sep 2023, at 11:57, Chris Dornan wrote:

Proposal: Amend or patterns (#522) to use p1 ; p2 (#609) Author: Sebastian Graf, David Knothe Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49... Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609 Recommendation: Acceptance

## Summary

This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns.

The syntax of the old proposal,

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (one of T2{}, T3{}) = Nothing ```

is replaced with

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (T2{}; T3{}) = Nothing ```

or indeed

```haskell stringOfT :: T -> Maybe String stringOfT x = case x of T1 s -> Just s T2{} T3{} -> Nothing ```

(Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.)

The authors have conducted polls to see what folks preferred, landing on this proposal. The adjustments to the Haskell grammar are really quite minimal requiring one extra production.

## Recommendation

The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend that we accept it

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Arnaud Spiwack

2 Oct 2 Oct

1:59 p.m.

I'm good too. On Sat, 30 Sept 2023 at 19:33, Eric Seidel wrote:

...

I'm happy with this change.

...
Sounds good to me.

On Fri, 29 Sep 2023 at 7:47 PM, Chris Dornan wrote:

...
All,

This proposal has now been revised to make it non-disruptive.

That was the only issue of substance that surfaced in our discussion and I recommend that we accept this revised proposal.

Chris

...
On 8 Sep 2023, at 11:57, Chris Dornan wrote:

Proposal: Amend or patterns (#522) to use p1 ; p2 (#609) Author: Sebastian Graf, David Knothe Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49... Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609 Recommendation: Acceptance

## Summary

This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns.

The syntax of the old proposal,

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (one of T2{}, T3{}) = Nothing ```

is replaced with

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (T2{}; T3{}) = Nothing ```

or indeed

```haskell stringOfT :: T -> Maybe String stringOfT x = case x of T1 s -> Just s T2{} T3{} -> Nothing ```

(Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.)

The authors have conducted polls to see what folks preferred, landing on this proposal. The adjustments to the Haskell grammar are really quite minimal requiring one extra production.

## Recommendation

The proposal is nondiruptive and as a whole addresses an important

On Fri, Sep 29, 2023, at 08:46, Moritz Angermann wrote: practical topic. I recommend

...
...
...
that we accept it

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

Simon Peyton Jones

3 Oct 3 Oct

10:17 a.m.

Chris *Joachim, Simon, and Richard *have yet to vote; but I think you have a majority anyway. Would you like to move this forward? Simon On Fri, 8 Sept 2023 at 11:57, Chris Dornan wrote:

...

Proposal: Amend or patterns (#522) to use p1 ; p2 (#609) Author: Sebastian Graf, David Knothe Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49... Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609 Recommendation: Acceptance

## Summary

This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns.

The syntax of the old proposal,

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (one of T2{}, T3{}) = Nothing ```

is replaced with

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (T2{}; T3{}) = Nothing ```

or indeed

```haskell stringOfT :: T -> Maybe String stringOfT x = case x of T1 s -> Just s T2{} T3{} -> Nothing ```

(Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.)

The authors have conducted polls to see what folks preferred, landing on this proposal. The adjustments to the Haskell grammar are really quite minimal requiring one extra production.

## Recommendation

The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend that we accept it

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

10:49 a.m.

New subject: Amend or patterns (#522) to use p1 ; p2 (#609)

Hi, ah, yes, I’m in favor! Cheers, Joachim Am Dienstag, dem 03.10.2023 um 11:17 +0100 schrieb Simon Peyton Jones:

...

Chris

Joachim, Simon, and Richard have yet to vote; but I think you have a majority anyway. Would you like to move this forward?

Simon

On Fri, 8 Sept 2023 at 11:57, Chris Dornan wrote:

...
Proposal: Amend or patterns (#522) to use p1 ; p2 (#609) Author: Sebastian Graf, David Knothe Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49... Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609 Recommendation: Acceptance

## Summary

This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns.

The syntax of the old proposal,

```haskell     stringOfT :: T -> Maybe String     stringOfT (T1 s) = Just s     stringOfT (one of T2{}, T3{}) = Nothing ```

is replaced with

```haskell     stringOfT :: T -> Maybe String     stringOfT (T1 s) = Just s     stringOfT (T2{}; T3{}) = Nothing ```

or indeed

```haskell     stringOfT :: T -> Maybe String     stringOfT x = case x of       T1 s -> Just s       T2{}       T3{} -> Nothing ```

(Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.)

The authors have conducted polls to see what folks preferred, landing on this proposal. The adjustments to the Haskell grammar are really quite minimal requiring one extra production.

## Recommendation

The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend that we accept it

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Richard Eisenberg

1:11 p.m.

New subject: Amend or patterns (#522) to use p1 ; p2 (#609)

I'm in support.

...

On Oct 3, 2023, at 6:49 AM, Joachim Breitner wrote:

Hi,

ah, yes, I’m in favor!

Cheers, Joachim

Am Dienstag, dem 03.10.2023 um 11:17 +0100 schrieb Simon Peyton Jones:

...
Chris

Joachim, Simon, and Richard have yet to vote; but I think you have a majority anyway. Would you like to move this forward?

Simon

On Fri, 8 Sept 2023 at 11:57, Chris Dornan wrote:

...
Proposal: Amend or patterns (#522) to use p1 ; p2 (#609) Author: Sebastian Graf, David Knothe Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49... Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609 Recommendation: Acceptance

## Summary

This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns.

The syntax of the old proposal,

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (one of T2{}, T3{}) = Nothing ```

is replaced with

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (T2{}; T3{}) = Nothing ```

or indeed

```haskell stringOfT :: T -> Maybe String stringOfT x = case x of T1 s -> Just s T2{} T3{} -> Nothing ```

(Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.)

The authors have conducted polls to see what folks preferred, landing on this proposal. The adjustments to the Haskell grammar are really quite minimal requiring one extra production.

## Recommendation

The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend that we accept it

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Chris Dornan

8 Oct 8 Oct

3:15 p.m.

New subject: Amend or patterns (#522) to use p1 ; p2 (#609)

The motion is carried. I have asked the authors to make some final changes proposed by Simon and Adam -- once that is done we can press the big green button.

...

On 3 Oct 2023, at 11:17, Simon Peyton Jones wrote:

Chris

Joachim, Simon, and Richard have yet to vote; but I think you have a majority anyway. Would you like to move this forward?

Simon

On Fri, 8 Sept 2023 at 11:57, Chris Dornan mailto:chris@chrisdornan.com> wrote:

...
Proposal: Amend or patterns (#522) to use p1 ; p2 (#609) Author: Sebastian Graf, David Knothe Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49... Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609 Recommendation: Acceptance

## Summary

This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns.

The syntax of the old proposal,

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (one of T2{}, T3{}) = Nothing ```

is replaced with

```haskell stringOfT :: T -> Maybe String stringOfT (T1 s) = Just s stringOfT (T2{}; T3{}) = Nothing ```

or indeed

```haskell stringOfT :: T -> Maybe String stringOfT x = case x of T1 s -> Just s T2{} T3{} -> Nothing ```

(Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.)

The authors have conducted polls to see what folks preferred, landing on this proposal. The adjustments to the Haskell grammar are really quite minimal requiring one extra production.

## Recommendation

The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend that we accept it

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

637

Age (days ago)

667

Last active (days ago)

List overview

Download

22 comments

10 participants

participants (10)

Adam Gundry
Arnaud Spiwack
Chris Dornan
Eric Seidel
Joachim Breitner
Moritz Angermann
Richard Eisenberg
Simon Marlow
Simon Peyton Jones
Vladislav Zavialov

Amend or patterns (#522) to use p1 ; p2 (#609)

tags

participants (10)