[ghc-steering-committee] Proposal #522: Or patterns. Recommendation: accept

[Simon Marlow]

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 <lists at richarde.dev> wrote:

> Any other thoughts here? I plan to accept next week.
>
> Thanks,
> Richard
>
> > On Aug 24, 2022, at 7:49 AM, Chris Dornan <chris at chrisdornan.com> wrote:
> >
> > Count me in — yes to Or patterns for me.
> >
> >> On 2022-08-24, at 11:57, Simon Peyton Jones <
> simon.peytonjones at 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 <lists at richarde.dev>
> 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-patterns.rst
> >> 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-patterns.rst#id12)
> 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 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/20221018/600bd758/attachment.html>