Count me in — yes to Or patterns for me.

On 2022-08-24, at 11:57, Simon Peyton Jones wrote:

I'm mildly in favour of acceptance. One more thing. But a reasonably easy thing.

Simon

On Fri, 19 Aug 2022 at 22:23, Richard Eisenberg wrote: Hi all,

I have been assigned to shepherd Proposal #522, Or patterns.

Proposal text: https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patte... Proposal discussion: https://github.com/ghc-proposals/ghc-proposals/pull/522

The proposal introduces a syntax for or-patterns. Here is an example:

case ... of K1 a b c -> Just ... K2 d e -> Just ... (K3 {} ; K4 {} ; K5 {}) -> Nothing

Summary

Without this proposal, the author of the above code would have to either use a _ pattern for the last line, meaning that future new constructors added to the datatype would go unreported by compiler warnings, or to write the K3, K4, and K5 cases separately, repeating the right-hand side. Or-patterns are common in other languages.

The authors include a nice section (https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patte...) on alternative syntax. I recommend reading it; it made me feel better about the proposed semi-colon syntax.

The proposal requires that each pattern in an or-pattern must not bind any variables. Any provided contexts (e.g. GADT equalities) and existential variables are ignored, and any required context is combined across the disjuncts in the pattern.

Two implementors are named in the proposal.

Recommendation

I recommend acceptance. This proposal is relatively simple, will lead to a nice quality-of-life improvement, is future-compatible (*) with or-patterns that do bind variables/contexts/existentials, and has a natural reading to users unfamiliar with the extension.

(*): I suppose that the fact that an or-pattern discards equalities might mean that a later improvement that retains these equalities might interfere with type inference (because in-scope equalities cause type variables to become untouchable). But I will choose not to worry about this.

The downsides are: - Yet another feature to think about, including a new extension name. - Yet another feature to implement and maintain.

I think the improvements to the language are worth these downsides, though I could be convinced otherwise.

Please let me know what you think about this proposal. I'm hoping to accept this proposal in three weeks (a bit longer than my usual timeframe, due to it being a popular time for holidays), unless there is objection.

Thanks! Richard _______________________________________________ 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

The syntax is quite unsatisfying, reusing a symbol that has a different meaning in expressions. Such a shame that | was used for guards. Oh well. It's a useful feature though, I'm weakly in favour. Simon On Fri, 2 Sept 2022 at 17:36, Richard Eisenberg wrote:

Any other thoughts here? I plan to accept next week.

Thanks, Richard

...

On Aug 24, 2022, at 7:49 AM, Chris Dornan wrote:

Count me in — yes to Or patterns for me.

...

On 2022-08-24, at 11:57, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

I'm mildly in favour of acceptance. One more thing. But a reasonably easy thing.

Simon

On Fri, 19 Aug 2022 at 22:23, Richard Eisenberg wrote: Hi all,

I have been assigned to shepherd Proposal #522, Or patterns.

Proposal text: https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patte... Proposal discussion: https://github.com/ghc-proposals/ghc-proposals/pull/522

The proposal introduces a syntax for or-patterns. Here is an example:

case ... of K1 a b c -> Just ... K2 d e -> Just ... (K3 {} ; K4 {} ; K5 {}) -> Nothing

Summary

Without this proposal, the author of the above code would have to either use a _ pattern for the last line, meaning that future new constructors added to the datatype would go unreported by compiler warnings, or to write the K3, K4, and K5 cases separately, repeating the right-hand side. Or-patterns are common in other languages.

The authors include a nice section ( https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patte...) on alternative syntax. I recommend reading it; it made me feel better about the proposed semi-colon syntax.

The proposal requires that each pattern in an or-pattern must not bind any variables. Any provided contexts (e.g. GADT equalities) and existential variables are ignored, and any required context is combined across the disjuncts in the pattern.

Two implementors are named in the proposal.

Recommendation

I recommend acceptance. This proposal is relatively simple, will lead to a nice quality-of-life improvement, is future-compatible (*) with or-patterns that do bind variables/contexts/existentials, and has a natural reading to users unfamiliar with the extension.

(*): I suppose that the fact that an or-pattern discards equalities might mean that a later improvement that retains these equalities might interfere with type inference (because in-scope equalities cause type variables to become untouchable). But I will choose not to worry about this.

The downsides are: - Yet another feature to think about, including a new extension name. - Yet another feature to implement and maintain.

I think the improvements to the language are worth these downsides, though I could be convinced otherwise.

Please let me know what you think about this proposal. I'm hoping to accept this proposal in three weeks (a bit longer than my usual timeframe, due to it being a popular time for holidays), unless there is objection.

Thanks! Richard _______________________________________________ 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