<div dir="ltr">I am also for accepting this, especially if we use one of the alternative notations (I just posted another variation on the github ticket)</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 18, 2018 at 9:12 AM Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu">rae@cs.brynmawr.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, I'm in favor of accepting.<br>
<br>
> On Jun 18, 2018, at 9:02 AM, Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>> wrote:<br>
> <br>
> Dear steering committee<br>
> <br>
> The or-pattern proposal has teen "under consideration" by this committee since 19 August 2017. That is nearly a year!<br>
> <br>
> I think we can decide. I favour acceptance subject to the points in my comment here<br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-395906439" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-395906439</a><br>
> <br>
> 1. Typing rules, dealing with existentials, dictionaries etc. <br>
> I make a concrete proposal and would welcome critique.<br>
> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-396851582" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-396851582</a><br>
> <br>
> 2. Syntax. I really think we should not use "|" because we already use that<br>
> for guards -- and moreover (as the comment says) there's an obvious way to<br>
> use guards *in* patterns not just *after* patterns.<br>
> <br>
> If not "|" then what? I'm ok with ";". But I guess "||" could also be considered.<br>
> <br>
> I think we owe it to the proposer not to drag our feet any more.<br>
> <br>
> Simon<br>
> <br>
> <br>
> | -----Original Message-----<br>
> | From: ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>> On<br>
> | Behalf Of Manuel M T Chakravarty<br>
> | Sent: 01 November 2017 23:58<br>
> | To: <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> | Subject: [ghc-steering-committee] Proposal: Or patterns (#43)<br>
> | <br>
> | Folks,<br>
> | <br>
> | I am sorry for taking a long time to get us going on this proposal.<br>
> | <br>
> | The ”Or pattern” proposal is about an extension to pattern matching:<br>
> | <br>
> | (formatted)<br>
> | <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%" rel="noreferrer" target="_blank">https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%</a><br>
> | 2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000-or-<br>
> | patterns.rst&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%7Cc41b6be72ad545030e3c08<br>
> | d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774805951860&s<br>
> | data=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D&reserved=0<br>
> | (PR thread)<br>
> | <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%" rel="noreferrer" target="_blank">https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%</a><br>
> | 2Fghc-proposals%2Fghc-<br>
> | proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%7Cc41b6be72ad54<br>
> | 5030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480<br>
> | 5951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmhw%3D&reserved=0<br>
> | <br>
> | Its basic idea is simple: allow multiple alternative patterns for each<br>
> | alternative during pattern matching. Unfortunately, the interaction with<br>
> | guards and some other languages features makes it significantly less<br>
> | straight forward than one might initially think.<br>
> | <br>
> | I propose to accept this proposal provided we can agree to use the ”first<br>
> | semantics” (aka single-match semantics) — see<br>
> | <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%" rel="noreferrer" target="_blank">https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%</a><br>
> | 2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000-or-<br>
> | patterns.rst%23interaction-with-<br>
> | guards&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%7Cc41b6be72ad545030e3c08d52184<br>
> | 6116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774805951860&sdata=Z<br>
> | 5JJApLfReiCl0dKD2R%2Fvbs3pTZt84iEXDRhdbeVICA%3D&reserved=0<br>
> | <br>
> | My reason for insisting on the first semantics is that it is a simple<br>
> | extension of the existing pattern semantics in the Report, whereas the<br>
> | second semantics requires a more profound, non-local change. This, in<br>
> | particular, also makes it easier to understand the implications of the first<br>
> | semantics. (Also, OCaml has made that same choice.)<br>
> | <br>
> | However, even with the first semantics, I still have one concern about this<br>
> | proposal. The story about the interaction with existential types is<br>
> | currently only partial and there is no discussion of the interaction with<br>
> | GADTs. It might be reasonable to ask for a complete specification of the<br>
> | interaction with these features before making a final determination on this<br>
> | proposal. Nevertheless, this proposal is quite elaborate and quite some work<br>
> | has gone into it. Hence, I think, we owe it the authors of the proposal to<br>
> | at least make a preliminary determination at this point. (In particular, if<br>
> | it is not going to fly regardless of how GADTs are handled, we should say so<br>
> | now.)<br>
> | <br>
> | Cheers,<br>
> | Manuel<br>
> | <br>
> | PS: It is worth noting that Swift solved the problem of deciding between the<br>
> | first and second semantics by choosing a syntax that avoids the ambiguity:<br>
> | <<a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper" rel="noreferrer" target="_blank">https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper</a>.<br>
> | <a href="http://apple.com" rel="noreferrer" target="_blank">apple.com</a>%2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConceptual%2FSwift_P<br>
> | rogramming_Language%2FStatements.html%23%2F%2Fapple_ref%2Fswift%2Fgrammar%2F<br>
> | switch-<br>
> | statement&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%7Cc41b6be72ad545030e3c08d52<br>
> | 1846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774805951860&sdat<br>
> | a=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&reserved=0>. It is<br>
> | difficult to adapt this syntax to Haskell. If it where possible, I think,<br>
> | this would be the best solution.<br>
> | _______________________________________________<br>
> | ghc-steering-committee mailing list<br>
> | <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> | <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>