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

[Iavor Diatchki]

I am also for accepting this, especially if we use one of the alternative
notations (I just posted another variation on the github ticket)

On Mon, Jun 18, 2018 at 9:12 AM Richard Eisenberg <rae at cs.brynmawr.edu>
wrote:

> 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
>
> _______________________________________________
> 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/20180618/46e366c0/attachment-0001.html>