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

[Simon Peyton Jones]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220824/9b0bbb20/attachment.html>