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

[Richard Eisenberg]

Yes, I'm in favor of accepting.

> On Jun 18, 2018, at 9:02 AM, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> 
> Dear steering committee
> 
> The or-pattern proposal has teen "under consideration" by this committee since 19 August 2017.  That is nearly a year!
> 
> I think we can decide. I favour acceptance subject to the points in my comment here
> https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-395906439
> 
> 1. Typing rules, dealing with existentials, dictionaries etc.  
>   I make a concrete proposal and would welcome critique.
>   https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-396851582
> 
> 2. Syntax.  I really think we should not use "|" because we already use that
>   for guards -- and moreover (as the comment says) there's an obvious way to
>   use guards *in* patterns not just *after* patterns.
> 
>   If not "|" then what? I'm ok with ";".   But I guess "||" could also be considered.
> 
> I think we owe it to the proposer not to drag our feet any more.
> 
> Simon
> 
> 
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On
> |  Behalf Of Manuel M T Chakravarty
> |  Sent: 01 November 2017 23:58
> |  To: ghc-steering-committee at haskell.org
> |  Subject: [ghc-steering-committee] Proposal: Or patterns (#43)
> |  
> |  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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
> |  2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000-or-
> |  patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08
> |  d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774805951860&s
> |  data=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D&reserved=0
> |    (PR thread)
> |  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
> |  2Fghc-proposals%2Fghc-
> |  proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad54
> |  5030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480
> |  5951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmhw%3D&reserved=0
> |  
> |  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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
> |  2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000-or-
> |  patterns.rst%23interaction-with-
> |  guards&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08d52184
> |  6116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774805951860&sdata=Z
> |  5JJApLfReiCl0dKD2R%2Fvbs3pTZt84iEXDRhdbeVICA%3D&reserved=0
> |  
> |  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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.
> |  apple.com%2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConceptual%2FSwift_P
> |  rogramming_Language%2FStatements.html%23%2F%2Fapple_ref%2Fswift%2Fgrammar%2F
> |  switch-
> |  statement&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08d52
> |  1846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774805951860&sdat
> |  a=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&reserved=0>. 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
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee