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

[Simon Peyton Jones]

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