[ghc-steering-committee] Proposal: Or patterns (#43)

[Simon Marlow]

I'm in favour of Or patterns with the non-backtracking semantics. While '|'
is the natural syntax, it does have a couple of drawbacks:

- it's the same as the guard syntax, and therefore potentially confusing
(it might not seem confusing to us, because we're used to parsing Haskell
in our heads, but to new users I'm sure this will be confusing)
- It interacts badly with this idea which I really hope we can make into a
proper proposal one day:
https://ghc.haskell.org/trac/ghc/wiki/ViewPatternsAlternative

But '|' is also the syntax used for defining the constructor alternatives
in a data type. So unless we intend to recommend GADT syntax exclusively in
the future, it makes sense to use '|' for or-patterns. And I can't think of
a good alternative.

Cheers,
Simon


On 1 November 2017 at 23:57, Manuel M T Chakravarty <chak at justtesting.org>
wrote:

> Folks,
>
> I am sorry for taking a long time to get us going on this proposal.
>
> The ”Or pattern” proposal is about an extension to pattern matching:
>
>   (formatted) https://github.com/osa1/ghc-proposals/blob/or_patterns/
> proposals/0000-or-patterns.rst
>   (PR thread) https://github.com/ghc-proposals/ghc-proposals/pull/43
>
> Its basic idea is simple: allow multiple alternative patterns for each
> alternative during pattern matching. Unfortunately, the interaction with
> guards and some other languages features makes it significantly less
> straight forward than one might initially think.
>
> I propose to accept this proposal provided we can agree to use the ”first
> semantics” (aka single-match semantics) — see https://github.com/osa1/ghc-
> proposals/blob/or_patterns/proposals/0000-or-patterns.
> rst#interaction-with-guards
>
> My reason for insisting on the first semantics is that it is a simple
> extension of the existing pattern semantics in the Report, whereas the
> second semantics requires a more profound, non-local change. This, in
> particular, also makes it easier to understand the implications of the
> first semantics. (Also, OCaml has made that same choice.)
>
> However, even with the first semantics, I still have one concern about
> this proposal. The story about the interaction with existential types is
> currently only partial and there is no discussion of the interaction with
> GADTs. It might be reasonable to ask for a complete specification of the
> interaction with these features before making a final determination on this
> proposal. Nevertheless, this proposal is quite elaborate and quite some
> work has gone into it. Hence, I think, we owe it the authors of the
> proposal to at least make a preliminary determination at this point. (In
> particular, if it is not going to fly regardless of how GADTs are handled,
> we should say so now.)
>
> Cheers,
> Manuel
>
> PS: It is worth noting that Swift solved the problem of deciding between
> the first and second semantics by choosing a syntax that avoids the
> ambiguity: <https://developer.apple.com/library/content/documentation/
> Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/
> swift/grammar/switch-statement>. It is difficult to adapt this syntax to
> Haskell. If it where possible, I think, this would be the best solution.
> _______________________________________________
> 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/20171102/f95bf204/attachment-0001.html>