I agree with all that you are saying about the syntax, including that I really don’t see a good alternative. I didn’t know about the view patterns alternative. That is indeed an annoying potential overlap. Cheers, Manuel

Simon Marlow :

I'm in favour of Or patterns with the non-backtracking semantics. While '|' is the natural syntax, it does have a couple of drawbacks:

- it's the same as the guard syntax, and therefore potentially confusing (it might not seem confusing to us, because we're used to parsing Haskell in our heads, but to new users I'm sure this will be confusing) - It interacts badly with this idea which I really hope we can make into a proper proposal one day: https://ghc.haskell.org/trac/ghc/wiki/ViewPatternsAlternative https://ghc.haskell.org/trac/ghc/wiki/ViewPatternsAlternative

But '|' is also the syntax used for defining the constructor alternatives in a data type. So unless we intend to recommend GADT syntax exclusively in the future, it makes sense to use '|' for or-patterns. And I can't think of a good alternative.

Cheers, Simon

On 1 November 2017 at 23:57, Manuel M T Chakravarty mailto:chak@justtesting.org> wrote: 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://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-pat... https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-pat... (PR thread) https://github.com/ghc-proposals/ghc-proposals/pull/43 https://github.com/ghc-proposals/ghc-proposals/pull/43

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://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-pat... https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-pat...

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://developer.apple.com/library/content/documentation/Swift/Conceptual/S... https://developer.apple.com/library/content/documentation/Swift/Conceptual/S...>. 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@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

You are right, the proposal must be complete before we can accept it. What I would like to suggest is the following: * If we all agree that *so far* this proposal is acceptable, we bounce it back to the authors saying that if they are able to fill in the gaps (especially, the treatment of GADTs) in a satisfactory manner, we will accept the proposal. * If we decide to reject the proposal, the authors can save themselves the effort of completing the specification. I know that this deviates from our usual procedure, but for a rather large piece of work that does show promise, I think, it is worthwhile to show some respect and appreciation for the effort spent. Cheers, Manuel

Simon Peyton Jones :

In general I'm ok with this proposal.

But I've just added a comment explaining some things that really need fleshing out.

* The proposal should specify that in (p1 | p2) the patterns in p1 and p2 must bind the same set of variables, with the same types. Nothing else makes sense; but it is nowhere specified.

* I'm concerned that the specification is incomplete. Certainly when it comes to GADTs there is some muttering about the prototype implementation, but no specification.

* For GADTs it's clear to me that in (p1 | p2) the patterns p1 and p2 should bind the same set of existentials and the same set of type constraints (including class constraints), just as they must bind the same set of variables with the same types. Just write out the typing rules for patterns (which should be part of the proposal) and it'll all become clear!

* I'm bothered by the stuff about view patterns, lazy patterns etc in the proposal. The point is: or-patterns has NO interaction with these patterns. We should just say that and stop! By having (quite long) sections about these features, but not (say) about tuple patterns, the implication is that there is something special to say. But there isn't.

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

Definitely non-backtracking. The backtracking thing opens up a whole new can of worms.

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

I agree with that... but I'd be reluctant to actually accept it into GHC unless it was fully compositional, including GADTs. So it'd be a conditional acceptance, subject to satisfactory resolution of the GADT question. I'm not sure how the implementation works out... let's see; probably fine.

Simon

| -----Original Message----- | From: ghc-steering-committee [mailto: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%2Fgithu | b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- | or- | patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad54503 | 0e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177 | 4805951860&sdata=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D& | reserved=0 | (PR thread) | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | b.com%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be | 72ad545030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 | C636451774805951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmh | w%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%2Fgithu | b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- | or-patterns.rst%23interaction-with- | guards&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08 | d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480595 | 1860&sdata=Z5JJApLfReiCl0dKD2R%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%2Fdeve | loper.apple.com%2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConceptu | al%2FSwift_Programming_Language%2FStatements.html%23%2F%2Fapple_ref%2F | swift%2Fgrammar%2Fswitch- | statement&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3 | c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480 | 5951860&sdata=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&reser | ved=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@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee

Hi, from a procedural point of view, that’s fine: We can certainly ask for improvements to a proposal, and there is even a “Needs revision” label for it. Joachim Am Freitag, den 03.11.2017, 10:40 +1100 schrieb Manuel M T Chakravarty:

You are right, the proposal must be complete before we can accept it. What I would like to suggest is the following:

* If we all agree that *so far* this proposal is acceptable, we bounce it back to the authors saying that if they are able to fill in the gaps (especially, the treatment of GADTs) in a satisfactory manner, we will accept the proposal.

* If we decide to reject the proposal, the authors can save themselves the effort of completing the specification.

I know that this deviates from our usual procedure, but for a rather large piece of work that does show promise, I think, it is worthwhile to show some respect and appreciation for the effort spent.

Cheers, Manuel

...

Simon Peyton Jones :

In general I'm ok with this proposal.

But I've just added a comment explaining some things that really need fleshing out.

* The proposal should specify that in (p1 | p2) the patterns in p1 and p2 must bind the same set of variables, with the same types. Nothing else makes sense; but it is nowhere specified.

* I'm concerned that the specification is incomplete. Certainly when it comes to GADTs there is some muttering about the prototype implementation, but no specification.

* For GADTs it's clear to me that in (p1 | p2) the patterns p1 and p2 should bind the same set of existentials and the same set of type constraints (including class constraints), just as they must bind the same set of variables with the same types. Just write out the typing rules for patterns (which should be part of the proposal) and it'll all become clear!

* I'm bothered by the stuff about view patterns, lazy patterns etc in the proposal. The point is: or-patterns has NO interaction with these patterns. We should just say that and stop! By having (quite long) sections about these features, but not (say) about tuple patterns, the implication is that there is something special to say. But there isn't.

...

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.

Definitely non-backtracking. The backtracking thing opens up a whole new can of worms.

...

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

I agree with that... but I'd be reluctant to actually accept it into GHC unless it was fully compositional, including GADTs. So it'd be a conditional acceptance, subject to satisfactory resolution of the GADT question. I'm not sure how the implementation works out... let's see; probably fine.

Simon

...

-----Original Message----- From: ghc-steering-committee [mailto: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%2Fgithu b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- or- patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad54503 0e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177 4805951860&sdata=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D& reserved=0 (PR thread) https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu b.com%2Fghc-proposals%2Fghc- proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be 72ad545030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 C636451774805951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmh w%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%2Fgithu b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- or-patterns.rst%23interaction-with- guards&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08 d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480595 1860&sdata=Z5JJApLfReiCl0dKD2R%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%2Fdeve loper.apple.com%2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConceptu al%2FSwift_Programming_Language%2FStatements.html%23%2F%2Fapple_ref%2F swift%2Fgrammar%2Fswitch- statement&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3 c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480 5951860&sdata=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&reser ved=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@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 -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

1. The syntax conflict with the view pattern proposal is unfortunate---I really like this idea, and I wrote up basically the exact same thing in my dissertation a long time ago, where I called it "guarded patterns". Very handy I think. Yes… I too wondered about ||, although then we’d run into trouble with definitions of the function (||). It seems hard to not-accept a proposal because it conflicts with another un-submitted one. But that’s just a question of specifying which wins in the ambiguous case p1 || p2 = e I like the fact that || is a bit noisier; we are using | for guards already. We should only allow it infix. Would someone like to submit the view-pattern proposal? For the second one, I can see two options: A) do not allow or patterns if any of the patterns contain constraint B) come up with a mechanism to compute the intersection of constraints I prefer (C): require exactly the same constraints bound in both patterns. Same as we require exactly the same variables bound. We could loosen up later. From: ghc-steering-committee [mailto:ghc-steering-committee-bounces@haskell.org] On Behalf Of Iavor Diatchki Sent: 07 November 2017 18:03 To: Joachim Breitner Cc: ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] Proposal: Or patterns (#43) Hello, I think that in principle the or-pattern patter idea is fine, but I am a bit wary of accepting it as is for two reasons: 1. The syntax conflict with the view pattern proposal is unfortunate---I really like this idea, and I wrote up basically the exact same thing in my dissertation a long time ago, where I called it "guarded patterns". Very handy I think. 2. The story about pattern contexts seems unclear (i.e., extistentials and GADTs). To work around the first one, how about we use double bar (i.e., ||) to separate the Or pattern? The single bar does feel more natural though... For the second one, I can see two options: A) do not allow or patterns if any of the patterns contain constraint B) come up with a mechanism to compute the intersection of constraints. For this I can see a few options: B.1) Fancy intersection, where the different branches of the or-patterns may define additional evidence bindings (be it dictionaries or coercions). B.2) Simple intersection, where we only pick constraints from the contexts that match exactly. -Iavor On Fri, Nov 3, 2017 at 6:19 AM Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Hi, from a procedural point of view, that’s fine: We can certainly ask for improvements to a proposal, and there is even a “Needs revision” label for it. Joachim Am Freitag, den 03.11.2017, 10:40 +1100 schrieb Manuel M T Chakravarty:

You are right, the proposal must be complete before we can accept it. What I would like to suggest is the following:

* If we all agree that *so far* this proposal is acceptable, we bounce it back to the authors saying that if they are able to fill in the gaps (especially, the treatment of GADTs) in a satisfactory manner, we will accept the proposal.

* If we decide to reject the proposal, the authors can save themselves the effort of completing the specification.

I know that this deviates from our usual procedure, but for a rather large piece of work that does show promise, I think, it is worthwhile to show some respect and appreciation for the effort spent.

Cheers, Manuel

...

Simon Peyton Jones mailto:simonpj@microsoft.com>:

In general I'm ok with this proposal.

But I've just added a comment explaining some things that really need fleshing out.

* The proposal should specify that in (p1 | p2) the patterns in p1 and p2 must bind the same set of variables, with the same types. Nothing else makes sense; but it is nowhere specified.

* I'm concerned that the specification is incomplete. Certainly when it comes to GADTs there is some muttering about the prototype implementation, but no specification.

* For GADTs it's clear to me that in (p1 | p2) the patterns p1 and p2 should bind the same set of existentials and the same set of type constraints (including class constraints), just as they must bind the same set of variables with the same types. Just write out the typing rules for patterns (which should be part of the proposal) and it'll all become clear!

* I'm bothered by the stuff about view patterns, lazy patterns etc in the proposal. The point is: or-patterns has NO interaction with these patterns. We should just say that and stop! By having (quite long) sections about these features, but not (say) about tuple patterns, the implication is that there is something special to say. But there isn't.

...

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.

Definitely non-backtracking. The backtracking thing opens up a whole new can of worms.

...

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

I agree with that... but I'd be reluctant to actually accept it into GHC unless it was fully compositional, including GADTs. So it'd be a conditional acceptance, subject to satisfactory resolution of the GADT question. I'm not sure how the implementation works out... let's see; probably fine.

Simon

...

-----Original Message----- From: ghc-steering-committee [mailto:ghc-steering-committee-mailto:ghc-steering-committee- bounces@haskell.orgmailto:bounces@haskell.org] On Behalf Of Manuel M T Chakravarty Sent: 01 November 2017 23:58 To: ghc-steering-committee@haskell.orgmailto: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%2Fgithu b.comhttps://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fb.com&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=vVnLieNrA5efYx9jbB%2BXtb%2FYWdKpO01CQMD2dj6Cwsg%3D&reserved=0%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- or- patterns.rst&data=02%7C01%7Csimonpj%40microsoft.comhttps://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=0I1KlIPm7n54A5ECKT91vmrrLLtKyLoeS9uD5dfzTG0%3D&reserved=0%7Cc41b6be72ad54503 0e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177 4805951860tel:(480)%20595-1860&sdata=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D& reserved=0 (PR thread) https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu b.comhttps://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fb.com&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=vVnLieNrA5efYx9jbB%2BXtb%2FYWdKpO01CQMD2dj6Cwsg%3D&reserved=0%2Fghc-proposals%2Fghc- proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.comhttps://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=0I1KlIPm7n54A5ECKT91vmrrLLtKyLoeS9uD5dfzTG0%3D&reserved=0%7Cc41b6be 72ad545030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 C636451774805951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmh w%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%2Fgithu b.comhttps://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fb.com&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=vVnLieNrA5efYx9jbB%2BXtb%2FYWdKpO01CQMD2dj6Cwsg%3D&reserved=0%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- or-patterns.rst%23interaction-with- guards&data=02%7C01%7Csimonpj%40microsoft.comhttps://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=0I1KlIPm7n54A5ECKT91vmrrLLtKyLoeS9uD5dfzTG0%3D&reserved=0%7Cc41b6be72ad545030e3c08 d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480595 1860&sdata=Z5JJApLfReiCl0dKD2R%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%2Fdeve loper.apple.comhttps://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Floper.apple.com&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=wCHBivwlq4sPM%2BVxMQIIwCzfjGwLKUf7c3xTgXUXtvg%3D&reserved=0%2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConceptu al%2FSwift_Programming_Language%2FStatements.html%23%2F%2Fapple_ref%2F swift%2Fgrammar%2Fswitch- statement&data=02%7C01%7Csimonpj%40microsoft.comhttps://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=0I1KlIPm7n54A5ECKT91vmrrLLtKyLoeS9uD5dfzTG0%3D&reserved=0%7Cc41b6be72ad545030e3 c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480 5951860&sdata=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&reser ved=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@haskell.orgmailto: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.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce4b67c3a21ee4058d49908d52609e766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636456746344878614&sdata=TyqRhlHt83F%2BCpZzF5kNM%2BI4YFj3GbLOGq5pNskVrbw%3D&reserved=0

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

Yes, I will do that. Thanks for the reminder. Cheers, Manuel

Am 06.01.2018 um 08:02 schrieb Joachim Breitner :

Hi Manuel,

not much discussion has happened here. Do you want to tell the authors about the changes that we would like to have fleshed out, so that we can get a better proposal back? Based on the discussion, I expect that a satisfactorially extended proposal to be accepted.

Cheers, Joachim

Am Freitag, den 03.11.2017, 10:40 +1100 schrieb Manuel M T Chakravarty:

...

You are right, the proposal must be complete before we can accept it. What I would like to suggest is the following:

* If we all agree that *so far* this proposal is acceptable, we bounce it back to the authors saying that if they are able to fill in the gaps (especially, the treatment of GADTs) in a satisfactory manner, we will accept the proposal.

* If we decide to reject the proposal, the authors can save themselves the effort of completing the specification.

I know that this deviates from our usual procedure, but for a rather large piece of work that does show promise, I think, it is worthwhile to show some respect and appreciation for the effort spent.

Cheers, Manuel

...

Simon Peyton Jones :

In general I'm ok with this proposal.

But I've just added a comment explaining some things that really need fleshing out.

* The proposal should specify that in (p1 | p2) the patterns in p1 and p2 must bind the same set of variables, with the same types. Nothing else makes sense; but it is nowhere specified.

* I'm concerned that the specification is incomplete. Certainly when it comes to GADTs there is some muttering about the prototype implementation, but no specification.

* For GADTs it's clear to me that in (p1 | p2) the patterns p1 and p2 should bind the same set of existentials and the same set of type constraints (including class constraints), just as they must bind the same set of variables with the same types. Just write out the typing rules for patterns (which should be part of the proposal) and it'll all become clear!

* I'm bothered by the stuff about view patterns, lazy patterns etc in the proposal. The point is: or-patterns has NO interaction with these patterns. We should just say that and stop! By having (quite long) sections about these features, but not (say) about tuple patterns, the implication is that there is something special to say. But there isn't.

...

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.

Definitely non-backtracking. The backtracking thing opens up a whole new can of worms.

...

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

I agree with that... but I'd be reluctant to actually accept it into GHC unless it was fully compositional, including GADTs. So it'd be a conditional acceptance, subject to satisfactory resolution of the GADT question. I'm not sure how the implementation works out... let's see; probably fine.

Simon

...

-----Original Message----- From: ghc-steering-committee [mailto: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%2Fgithu b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- or- patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad54503 0e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177 4805951860&sdata=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D& reserved=0 (PR thread) https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu b.com%2Fghc-proposals%2Fghc- proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be 72ad545030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 C636451774805951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmh w%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%2Fgithu b.com%2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000- or-patterns.rst%23interaction-with- guards&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08 d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480595 1860&sdata=Z5JJApLfReiCl0dKD2R%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%2Fdeve loper.apple.com%2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConceptu al%2FSwift_Programming_Language%2FStatements.html%23%2F%2Fapple_ref%2F swift%2Fgrammar%2Fswitch- statement&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3 c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480 5951860&sdata=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&reser ved=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@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 -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

---

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

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