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

[Manuel M T Chakravarty]

I agree with all that you are saying about the syntax, including that I really don’t see a good alternative.

I didn’t know about the view patterns alternative. That is indeed an annoying potential overlap.

Cheers,
Manuel

> Simon Marlow <marlowsd at gmail.com>:
> 
> 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 <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 <mailto: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 <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 <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 <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 <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 <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <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/20171103/aa43ef62/attachment.html>