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

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 wrote:

Yes, I'm in favor of accepting.

...

On Jun 18, 2018, at 9:02 AM, Simon Peyton Jones via ghc-steering-committee 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-39590643...

...

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-39685158...

...

2. Syntax. I really think we should not use "|" because we already use

...

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@haskell.org> On | Behalf Of Manuel M T Chakravarty | Sent: 01 November 2017 23:58 | To: ghc-steering-committee@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

...

| 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

...

| 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

...

| at least make a preliminary determination at this point. (In

...

| 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

that the first the proposal to particular, if think,

...

| this would be the best solution. | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee