Hi Richard - I'm curious about the coding style that you would advocate that uses it often. Can you give an example? Personally I thought I would use \case when we introduced it, but in practice I find I want it rarely enough that I actually don't use it even in the places where it would be marginally shorter, purely because I'm optimising for code readability and I don't think \case helps (one could go either way on that though). I do find MultiWayIf to be useful in practice - it looks nice, its meaning is obvious, and it helps code readability. But as I've said before I would never use it if it was called \cases :) Cheers Simon On Sat, 17 Jul 2021 at 03:29, Richard Eisenberg wrote:

I'm struggling with this one, so I'll procrastinate by asking two clarifying questions:

1. Why does (2) not subsume MultiWayIf? The example in the MultiWayIf note seems to work just fine with syntax (2).

2. (2) and (4) seem to lose \case{}, which is useful in practice. Am I correct in saying that we'll lose \case{}?

I said I'm struggling, so I will explain why: I really want this new syntax, and I would advocate a coding style that uses it often. But I'm quite concerned about language bloat, and I don't like adding a new construct without also planning to remove redundant ones. I'm not sure how to balance these two desires. Perhaps a night's sleep will yield insight.

Richard

On Jul 16, 2021, at 11:21 AM, Simon Peyton Jones via ghc-steering-committee wrote:

Friends

Sorry to be slow on #302: multi-way lambda. I was diverted by the POPL deadline.

I have not heard from Tom or Vitaly, I think, but I’ll take silence for agreement with the ballot list.

So it is time to vote!

Please go here https://docs.google.com/document/d/1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAIK..., and vote.

Feel free to add pros/cons to the list on that page.

*Please vote by next Thursday, 22 July, at the latest*. It’s a balance of judgement, for sure, not technically complicated.

Simon

*From:* Simon Peyton Jones *Sent:* 28 June 2021 10:45 *To:* ghc-steering-committee@haskell.org *Cc:* Simon Peyton Jones *Subject:* RE: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ)

Dear Steering Committee

Two weeks ago I asked

- *Are there any other alternatives you strongly want on the ballot?*

I got these responses

- Joachim, Simon, Alejandro, Arnaud: nothing to add - Vitaly, Eric, Tom, Richard, Vlad: no response

I’d love to hear from the five of you, please. I want to get a decision on this, and I can’t do that if I don’t hear from you.

Thanks

Simon

*From:* ghc-steering-committee

...

*On Behalf Of *Simon Peyton Jones via ghc-steering-committee *Sent:* 15 June 2021 13:52 *To:* Joachim Breitner ; ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ)

| I’d like to reassing shepherding of this one. | | It seems to be clear that we want “something like this”, there are many ways | to skin the cat, so it comes down to opinion and what we need is a decision | (or a call to votes). As with anything that’s possibly quite opinionated, | it’s good to have an authorative voice, so in this case, Simon PJ. | | Simon, can you either come up with a “all things considered, I think this | variant is the (narrowly) the best” recommendation or, alternative, a | “please vote on the following options” verdict?

OK, to remind everyone

- Here is the proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-l... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJakobBruenker%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2F0000-lambda-layout.md&data=04%7C01%7Csimonpj%40microsoft.com%7C4ae55d76732448a0c3a508d93a1955ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637604702751348160%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Hvxpaew8S333OX7IvW9cfD003mLSZxpjRdjOotGVZMA%3D&reserved=0 - Here is the discussion: https://github.com/ghc-proposals/ghc-proposals/pull/302 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302&data=04%7C01%7Csimonpj%40microsoft.com%7C4ae55d76732448a0c3a508d93a1955ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637604702751358154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1aYsUzlUaixOxNvW2%2FEkLNbImFD7yLBT273QFA76ZEI%3D&reserved=0

The basic idea is to extend to lambda all the facilities that you get with function definitions, especially multiple patterns and guards. This seems clearly a good idea, whose only obstacle is syntactic. There are no conceptual or specification challenges. The only point at issue is that of concrete syntax.

The proposal offers four possible syntactic options. After reviewing, I propose to discard (2) and (3) leaving these alternatives

- *Option (1) *\cases { p1 p2 -> rhs1; q1 q2 -> rhs2 }

- Lives alongside \case, but allows multiple patterns - Other keywords are possible, but I think it must be a variant on \case

- *Option (4)* Same, but use \case as the keyword

- Incompatible with existing \case => extended transition period, unhappy users - \case { (Just x) -> rhs1; Nothing -> rhs2 } will require parens forever, which in the common case of a one argument lambda see clunky.

- *Option (X).* Reject the proposal.

Personally I favour (1). I’m relaxed about having multiple ways of saying the thing (think of let vs where), and I see no harm provided the two constructs look and behave the same. I’ve decided I like \cases precisely because it’s the plural of \case, which is exactly what is going on.

I think we’ll end up having to vote on this, which is fine when it’s a judgement call about syntax. But first:

- *Are there any other alternatives you strongly want on the ballot?*

I say “strongly” because I don’t want to open up a big new debate… we at the stage of trying to narrow options.

Thanks

Simon _______________________________________________ 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

Thanks Richard. Personally, I'm very relaxed about adding an extra keyword to get more convenience. Haskell very consciously doesn't adhere to "there should be one way to do one thing". (Think let vs where, case vs if, and many others.) I'm relaxed, provided it carries low cognitive and explanatory overhead. And I think that is true of adding \cases to an existing \case. Another example: we could remove MultiWayIf if we had \cases. And yet, when there are zero args "if" is quite ergonomic. It's not 100% obvious to me that that it is worth removing it. Leaving it in, (1) give "if" = arity 0, \case = arity 1, \cases = any arity. Your questions are well targeted. 1. Why does (2) not subsume MultiWayIf? The example in the MultiWayIf note seems to work just fine with syntax (2). The proposal explicitly says n>=1 in the BNF. But I think you are right... n=0 would also be unambiguous. 2. (2) and (4) seem to lose \case{}, which is useful in practice. Am I correct in saying that we'll lose \case{}? Yes that too is true, and is a strike against (2) and (4). I have updated the voting pagehttps://docs.google.com/document/d/1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAIK... to reflect these observations. Simon From: Richard Eisenberg Sent: 17 July 2021 03:29 To: Simon Peyton Jones Cc: ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] Proposal #302: Multiway lambda: time to vote I'm struggling with this one, so I'll procrastinate by asking two clarifying questions: 1. Why does (2) not subsume MultiWayIf? The example in the MultiWayIf note seems to work just fine with syntax (2). 2. (2) and (4) seem to lose \case{}, which is useful in practice. Am I correct in saying that we'll lose \case{}? I said I'm struggling, so I will explain why: I really want this new syntax, and I would advocate a coding style that uses it often. But I'm quite concerned about language bloat, and I don't like adding a new construct without also planning to remove redundant ones. I'm not sure how to balance these two desires. Perhaps a night's sleep will yield insight. Richard On Jul 16, 2021, at 11:21 AM, Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote: Friends Sorry to be slow on #302: multi-way lambda. I was diverted by the POPL deadline. I have not heard from Tom or Vitaly, I think, but I'll take silence for agreement with the ballot list. So it is time to vote! Please go herehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAIKnDs%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7C79a033bdb2344b4e79af08d948caac09%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637620858630911674%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=paak7UdpMZrPMS4HtgqHJrsZun3%2Fi3oPxaMNaOxqpfs%3D&reserved=0, and vote. Feel free to add pros/cons to the list on that page. Please vote by next Thursday, 22 July, at the latest. It's a balance of judgement, for sure, not technically complicated. Simon From: Simon Peyton Jones mailto:simonpj@microsoft.com> Sent: 28 June 2021 10:45 To: ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org Cc: Simon Peyton Jones mailto:simonpj@microsoft.com> Subject: RE: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ) Dear Steering Committee Two weeks ago I asked * Are there any other alternatives you strongly want on the ballot? I got these responses * Joachim, Simon, Alejandro, Arnaud: nothing to add * Vitaly, Eric, Tom, Richard, Vlad: no response I'd love to hear from the five of you, please. I want to get a decision on this, and I can't do that if I don't hear from you. Thanks Simon From: ghc-steering-committee mailto:ghc-steering-committee-bounces@haskell.org> On Behalf Of Simon Peyton Jones via ghc-steering-committee Sent: 15 June 2021 13:52 To: Joachim Breitner mailto:mail@joachim-breitner.de>; ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ) | I'd like to reassing shepherding of this one. | | It seems to be clear that we want "something like this", there are many ways | to skin the cat, so it comes down to opinion and what we need is a decision | (or a call to votes). As with anything that's possibly quite opinionated, | it's good to have an authorative voice, so in this case, Simon PJ. | | Simon, can you either come up with a "all things considered, I think this | variant is the (narrowly) the best" recommendation or, alternative, a | "please vote on the following options" verdict? OK, to remind everyone * Here is the proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-l...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJakobBruenker%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2F0000-lambda-layout.md&data=04%7C01%7Csimonpj%40microsoft.com%7C4ae55d76732448a0c3a508d93a1955ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637604702751348160%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Hvxpaew8S333OX7IvW9cfD003mLSZxpjRdjOotGVZMA%3D&reserved=0 * Here is the discussion: https://github.com/ghc-proposals/ghc-proposals/pull/302https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302&data=04%7C01%7Csimonpj%40microsoft.com%7C4ae55d76732448a0c3a508d93a1955ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637604702751358154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1aYsUzlUaixOxNvW2%2FEkLNbImFD7yLBT273QFA76ZEI%3D&reserved=0 The basic idea is to extend to lambda all the facilities that you get with function definitions, especially multiple patterns and guards. This seems clearly a good idea, whose only obstacle is syntactic. There are no conceptual or specification challenges. The only point at issue is that of concrete syntax. The proposal offers four possible syntactic options. After reviewing, I propose to discard (2) and (3) leaving these alternatives * Option (1) \cases { p1 p2 -> rhs1; q1 q2 -> rhs2 } * Lives alongside \case, but allows multiple patterns * Other keywords are possible, but I think it must be a variant on \case * Option (4) Same, but use \case as the keyword * Incompatible with existing \case => extended transition period, unhappy users * \case { (Just x) -> rhs1; Nothing -> rhs2 } will require parens forever, which in the common case of a one argument lambda see clunky. * Option (X). Reject the proposal. Personally I favour (1). I'm relaxed about having multiple ways of saying the thing (think of let vs where), and I see no harm provided the two constructs look and behave the same. I've decided I like \cases precisely because it's the plural of \case, which is exactly what is going on. I think we'll end up having to vote on this, which is fine when it's a judgement call about syntax. But first: * Are there any other alternatives you strongly want on the ballot? I say "strongly" because I don't want to open up a big new debate... we at the stage of trying to narrow options. Thanks Simon _______________________________________________ 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-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C79a033bdb2344b4e79af08d948caac09%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637620858630921634%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1P8vKNf3KJPFYk2JGwu%2FUdBQTPDe%2Fc4yJG1yj%2Bc%2B1sU%3D&reserved=0

| > 2. (2) and (4) seem to lose \case{}, which is useful in practice. Am I | > correct in saying that we'll lose \case{}? | > | > Yes that too is true, and is a strike against (2) and (4). | | I'm confused, the proposal explicitly says Aha, yes, you are right. Under (2) and (4), * if you supply *any* clauses the thing desugars to a lambda with the arity specified by the clauses * if you supply *no* clauses, the thing desugars to a lambda with arity 1, namely \x. case x of {} I'll modify the voting page. Simon | -----Original Message----- | From: ghc-steering-committee On | Behalf Of Eric Seidel | Sent: 22 July 2021 14:39 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Proposal #302: Multiway lambda: time | to vote | | On Mon, Jul 19, 2021, at 05:53, Simon Peyton Jones via ghc-steering- | committee wrote: | > 2. (2) and (4) seem to lose \case{}, which is useful in practice. Am I | > correct in saying that we'll lose \case{}? | > | > Yes that too is true, and is a strike against (2) and (4). | | I'm confused, the proposal explicitly says | | > If no clauses are given, i.e. the expression in question if \case {}, how | many arguments this expression should take is ambiguous. However, currently, | with -XEmptyCase, this expression is already valid and takes a single | argument. Thus, to maintain backwards compatibility and for lack of a better | option, this proposal does not alter the behavior of this expression. | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com | %2FJakobBruenker%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2F0000-lambda- | layout.md%23alternative-2-comma-separated- | case&data=04%7C01%7Csimonpj%40microsoft.com%7C14976dfa458c469a46a008d94d | 1633d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637625580724196361%7CUnk | nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV | CI6Mn0%3D%7C3000&sdata=skhFsQ4rI354wZVyBFJndPfeWHAyba79MznmPNmlxIA%3D&am | p;reserved=0 | | What's the problem with this solution? \case {} can still be instantiated at | any arity, but it will explode after applying a single argument. | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C14976dfa458c469a46a00 | 8d94d1633d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637625580724196361% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=4exfYaewnD%2BqnYd%2BI64VRlsTtX2QnN8X0pukt17r | ZfA%3D&reserved=0

Let me make a last minute argument *against (1)*. My issue with (1) is similar to what Richard and Simon M have already raised, that we're adding a new piece of syntax that is redundant in principle with the existing \case. By that I mean that main reason for adding syntax for multi-arg case is concerns around back compat. If we could go back in time and revise the original \case syntax to support multiple arguments, would we still end up with a single-arg construct and a multi-arg construct? I think probably not. I do find \case itself useful, and would like to see it gain the ability to take multiple arguments, which is why I support (2). But it feels very clumsy to have to think about how many arguments we're taking when choosing syntax. This is a much smaller and local issue than choosing between let and where (which have a much larger affect on the overall code structure and layout), and so for me it doesn't rise to the level of warranting multiple choices of syntax. On Thu, Jul 22, 2021, at 11:36, Simon Peyton Jones via ghc-steering-committee wrote:

Vlad, Alejandro, Arnaud Today is the deadline. Please vote https://docs.google.com/document/d/1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAIK...! Thanks Simon

*From:* Simon Peyton Jones *Sent:* 16 July 2021 16:22 *To:* ghc-steering-committee@haskell.org *Cc:* Simon Peyton Jones *Subject:* Proposal #302: Multiway lambda: time to vote

Friends Sorry to be slow on #302: multi-way lambda. I was diverted by the POPL deadline. I have not heard from Tom or Vitaly, I think, but I’ll take silence for agreement with the ballot list. So it is time to vote! Please go here https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAIKnDs%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7C5d7b8dd342144930392308d9486d710b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637620457141403003%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BAUVgyDZPoNjubavEBUhPYo5TGMRIfcPB5Q%2FQ5%2BkK2Q%3D&reserved=0, and vote. Feel free to add pros/cons to the list on that page. *Please vote by next Thursday, 22 July, at the latest*. It’s a balance of judgement, for sure, not technically complicated. Simon

*From:* Simon Peyton Jones *Sent:* 28 June 2021 10:45 *To:* ghc-steering-committee@haskell.org *Cc:* Simon Peyton Jones *Subject:* RE: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ)

Dear Steering Committee Two weeks ago I asked * *Are there any other alternatives you *strongly* want on the ballot?*

I got these responses * Joachim, Simon, Alejandro, Arnaud: nothing to add * Vitaly, Eric, Tom, Richard, Vlad: no response I’d love to hear from the five of you, please. I want to get a decision on this, and I can’t do that if I don’t hear from you. Thanks Simon

*From:* ghc-steering-committee *On Behalf Of *Simon Peyton Jones via ghc-steering-committee *Sent:* 15 June 2021 13:52 *To:* Joachim Breitner ; ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ)

| I’d like to reassing shepherding of this one.

|

| It seems to be clear that we want “something like this”, there are many ways

| to skin the cat, so it comes down to opinion and what we need is a decision

| (or a call to votes). As with anything that’s possibly quite opinionated,

| it’s good to have an authorative voice, so in this case, Simon PJ.

|

| Simon, can you either come up with a “all things considered, I think this

| variant is the (narrowly) the best” recommendation or, alternative, a

| “please vote on the following options” verdict?

OK, to remind everyone

* Here is the proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-l... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJakobBruenker%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2F0000-lambda-layout.md&data=04%7C01%7Csimonpj%40microsoft.com%7C4ae55d76732448a0c3a508d93a1955ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637604702751348160%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Hvxpaew8S333OX7IvW9cfD003mLSZxpjRdjOotGVZMA%3D&reserved=0 * Here is the discussion: https://github.com/ghc-proposals/ghc-proposals/pull/302 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302&data=04%7C01%7Csimonpj%40microsoft.com%7C4ae55d76732448a0c3a508d93a1955ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637604702751358154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1aYsUzlUaixOxNvW2%2FEkLNbImFD7yLBT273QFA76ZEI%3D&reserved=0

The basic idea is to extend to lambda all the facilities that you get with function definitions, especially multiple patterns and guards. This seems clearly a good idea, whose only obstacle is syntactic. There are no conceptual or specification challenges. The only point at issue is that of concrete syntax.

The proposal offers four possible syntactic options. After reviewing, I propose to discard (2) and (3) leaving these alternatives

* *Option (1) *\cases { p1 p2 -> rhs1; q1 q2 -> rhs2 } * Lives alongside \case, but allows multiple patterns * Other keywords are possible, but I think it must be a variant on \case * *Option (4)* Same, but use \case as the keyword * Incompatible with existing \case => extended transition period, unhappy users * \case { (Just x) -> rhs1; Nothing -> rhs2 } will require parens forever, which in the common case of a one argument lambda see clunky. * *Option (X).* Reject the proposal.

Personally I favour (1). I’m relaxed about having multiple ways of saying the thing (think of let vs where), and I see no harm provided the two constructs look and behave the same. I’ve decided I like \cases precisely because it’s the plural of \case, which is exactly what is going on. I think we’ll end up having to vote on this, which is fine when it’s a judgement call about syntax. But first: * *Are there any other alternatives you *strongly* want on the ballot?* I say “strongly” because I don’t want to open up a big new debate… we at the stage of trying to narrow options. Thanks Simon _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Thu, Jul 22, 2021, at 12:54, Simon Peyton Jones wrote:

Thanks Eric

| adding syntax for multi-arg case is concerns around back compat. If we could | go back in time and revise the original \case syntax to support multiple | arguments, would we still end up with a single-arg construct and a multi-arg | construct? I think probably not.

Actually I don't agree. I think we might well have \case (for 1) and \cases (for 0-n) because * the cognitive overhead is vanishingly small (especially given the singular/plural form * the absence of parens in the very common case of \case is extremely convenient

I actively like the signal that \cases gives me, up front, "here comes an nary lambda", rather than the very quiet commas of (2). Whereas I know that \case is always unary.

We don't have separate unary / n-ary constructs for function definitions or lambdas. Do you think we should make the distinction there too? I don't understand what makes \case so different. The paren issue is valid, but in my opinion option (2) solves it better with the comma separators.

Hi, on the multiway-lambda story, we have voted to add \cases alongside \case. But one open question is still: Do we  (1) add -XLambdaCases (which would imply -XLambdaCase) or (2) simply expand the meaning of -XLambdaCase. On the Github thread at https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-8950800... we see that I lean towards (1), but SPJ leands towards (2). It doesn’t matter that much, but we need to make a decision. Can I please get some opinions from the rest of the committee on this point? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Hi, I don’t think language pragmas are about choice in that sense. Either we don’t want the feature (then we’d reject it), or we want it to eventually become a viable default (at least for add-on extensions like this). So at some day I expect GHC20xx to allow both \case and \cases. Nobody forces to to _use_ \cases in your code, however! The question is more about: do we want extensions to evolve over time, or be more immutable (I don’t think we want to commit to full immutability). Cheers, Joachim Am Dienstag, dem 14.09.2021 um 10:55 +0300 schrieb Vladislav Zavialov (int-index):

We should give our users the option to keep using LambdaCase without enabling LambdaCases. I, for one, do not like the flavor we ended up choosing, so I’d keep using LambdaCase alone in my programs. I imagine other users might want to do so as well.

- Vlad

...

On 14 Sep 2021, at 10:38, Joachim Breitner wrote:

Hi,

on the multiway-lambda story, we have voted to add \cases alongside \case. But one open question is still: Do we (1) add -XLambdaCases (which would imply -XLambdaCase) or (2) simply expand the meaning of -XLambdaCase.

On the Github thread at https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-8950800... we see that I lean towards (1), but SPJ leands towards (2).

It doesn’t matter that much, but we need to make a decision. Can I please get some opinions from the rest of the committee on this point?

Cheers, Joachim

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

_______________________________________________ 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/

I vote (2). We have so many extensions already -- I don't see the need for another. Richard

On Sep 14, 2021, at 3:38 AM, Joachim Breitner wrote:

Hi,

on the multiway-lambda story, we have voted to add \cases alongside \case. But one open question is still: Do we (1) add -XLambdaCases (which would imply -XLambdaCase) or (2) simply expand the meaning of -XLambdaCase.

On the Github thread at https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-8950800... we see that I lean towards (1), but SPJ leands towards (2).

It doesn’t matter that much, but we need to make a decision. Can I please get some opinions from the rest of the committee on this point?

Cheers, Joachim

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

Vitaly, Eric, Tom, Alejandro As Joachim says, we need to make a decision on the LambdaCase flag issue. It's a judgement call, so let's just vote. Here is the voting sheethttps://docs.google.com/document/d/1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAIK.... I have filled in votes from Simon, myself, Joacim, Richard, Vlad. But four of us (in the to: line) have not expressed an opinion. Could you do so please, in the next day or two? It should take you 5 minutes. Thanks Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.com will cease to work. Use simon.peytonjones@gmail.com instead. (For now, it just forwards to simonpj@microsoft.com.) | -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 14 September 2021 08:39 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Proposal #302: Multiway lambda: | new extension or not? | | Hi, | | | on the multiway-lambda story, we have voted to add \cases alongside | \case. But one open question is still: Do we | (1) add -XLambdaCases (which would imply -XLambdaCase) or | (2) simply expand the meaning of -XLambdaCase. | | On the Github thread at | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com... | ub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com... | 895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a8831943459https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com... | 9cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376720https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com... | 20597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com... | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2ySitCA%2FT1uUznezDYhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com... | UKIO8g2ImLMKlnxm1OpKOXKZg%3D&reserved=0https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com... | we see that I lean towards (1), but SPJ leands towards (2). | | It doesn't matter that much, but we need to make a decision. Can I | please get some opinions from the rest of the committee on this point? | | Cheers, | Joachim | | | -- | Joachim Breitner | mail@joachim-breitner.demailto:mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim... | oachim-https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim... | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim... | 434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim... | 7672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiVhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim... | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=unmdYu9zUy00ec4https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim... | 21KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&reserved=0https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim... | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske... | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske... | committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a8831943459https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske... | 9cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376720https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske... | 20597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske... | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TG3t%2Fw1kFLk173SoM5https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske... | soHU39BlAPv76TY%2B9FNetaLJs%3D&reserved=0https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske...

Vitaly, Tom Are you there? I'd love to hear from you about this. Thanks Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.commailto:simonpj@microsoft.com will cease to work. Use simon.peytonjones@gmail.commailto:simon.peytonjones@gmail.com instead. (For now, it just forwards to simonpj@microsoft.com.) From: Simon Peyton Jones Sent: 15 September 2021 13:00 To: ghc-steering-committee@haskell.org Cc: Simon Peyton Jones Subject: RE: [ghc-steering-committee] Proposal #302: Multiway lambda: new extension or not? Vitaly, Eric, Tom, Alejandro As Joachim says, we need to make a decision on the LambdaCase flag issue. It's a judgement call, so let's just vote. Here is the voting sheethttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAIKnDs%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277542395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jzU6mlExltnKz2q0FPK%2Bm5wTCqXANQJMD7cmJESk85Q%3D&reserved=0. I have filled in votes from Simon, myself, Joacim, Richard, Vlad. But four of us (in the to: line) have not expressed an opinion. Could you do so please, in the next day or two? It should take you 5 minutes. Thanks Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj@microsoft.commailto:simonpj@microsoft.com will cease to work. Use simon.peytonjones@gmail.commailto:simon.peytonjones@gmail.com instead. (For now, it just forwards to simonpj@microsoft.commailto:simonpj@microsoft.com.) | -----Original Message----- | From: ghc-steering-committee mailto:bounces@haskell.org> On Behalf Of Joachim Breitner | Sent: 14 September 2021 08:39 | To: ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Proposal #302: Multiway lambda: | new extension or not? | | Hi, | | | on the multiway-lambda story, we have voted to add \cases alongside | \case. But one open question is still: Do we | (1) add -XLambdaCases (which would imply -XLambdaCase) or | (2) simply expand the meaning of -XLambdaCase. | | On the Github thread at | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277552385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UQfSypCiZZsQP%2Bu8DD%2BrWAl%2BbVysyXwYkwWJSrvdGH0%3D&reserved=0 | ub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277552385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UQfSypCiZZsQP%2Bu8DD%2BrWAl%2BbVysyXwYkwWJSrvdGH0%3D&reserved=0 | 895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a8831943459https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277562383%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Fz8Ac4%2FZsxyb%2BZTVzPf4vLUrBW2aLyWkHHVk96Kl86Q%3D&reserved=0 | 9cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376720https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277572379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZvWJy8VOnYChUkEu0Uz3I3i4txgrawqt06KdkKlvdts%3D&reserved=0 | 20597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277582374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AnU0eKL8ak%2FVQXBYaGgc972ZFJQyh1wMKyFazp%2Fgg60%3D&reserved=0 | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2ySitCA%2FT1uUznezDYhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277582374%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AnU0eKL8ak%2FVQXBYaGgc972ZFJQyh1wMKyFazp%2Fgg60%3D&reserved=0 | UKIO8g2ImLMKlnxm1OpKOXKZg%3D&reserved=0https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277592367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=W9Rq1zlL1DXKExX%2B2XLVl0olo74BKhF1JuelgGySimI%3D&reserved=0 | we see that I lean towards (1), but SPJ leands towards (2). | | It doesn't matter that much, but we need to make a decision. Can I | please get some opinions from the rest of the committee on this point? | | Cheers, | Joachim | | | -- | Joachim Breitner | mail@joachim-breitner.demailto:mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277602365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Dlo%2FKTIzbaLYOyi0%2F0rk9U7ZXoRpCMg7TQrq4g7vj9E%3D&reserved=0 | oachim-https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277602365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Dlo%2FKTIzbaLYOyi0%2F0rk9U7ZXoRpCMg7TQrq4g7vj9E%3D&reserved=0 | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88319https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277612365%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=raBLXrB3GJ2oSrmIysrHs0X%2FtzPlt3hojkvp6v3lVdU%3D&reserved=0 | 434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277622356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8gwNMFe4MOayMSiczhBy16AvhKiaq7TY%2BuWcNjoAr%2FQ%3D&reserved=0 | 7672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiVhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277622356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8gwNMFe4MOayMSiczhBy16AvhKiaq7TY%2BuWcNjoAr%2FQ%3D&reserved=0 | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=unmdYu9zUy00ec4https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277632352%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dNhxQH7oR41rjrD7USKU%2F2Rhm%2Bo2qnQFoKdi3WjoqIc%3D&reserved=0 | 21KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&reserved=0https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277642348%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UrzlZdQeq29XEiWbdAeQH%2BGi4%2BpOIqka6IeJ%2BAuJ9qc%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277652345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZNSPu2k360KVWAJ9poqlO56owNYi5pxCS8P6vvEpyUE%3D&reserved=0 | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277652345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZNSPu2k360KVWAJ9poqlO56owNYi5pxCS8P6vvEpyUE%3D&reserved=0 | committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a8831943459https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277662342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LSFYEN4qQBFd7t4o2CGuEyjUibTaZvdjDgzunCNl2YU%3D&reserved=0 | 9cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376720https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277672335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1QJDcC8pGcNlNNpUkLZ%2B%2FTjLeDpXPCf7sIDI0%2FtT1FU%3D&reserved=0 | 20597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277672335%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1QJDcC8pGcNlNNpUkLZ%2B%2FTjLeDpXPCf7sIDI0%2FtT1FU%3D&reserved=0 | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TG3t%2Fw1kFLk173SoM5https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277682330%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=87FhXp16tqtDe3%2BB099uId0JRDBhSf5uaxKC9Lg%2Bh%2BQ%3D&reserved=0 | soHU39BlAPv76TY%2B9FNetaLJs%3D&reserved=0https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb511339e197947e7541d08d9784067da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637673040277692329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=olFbP%2BA3I3L4lBZxAcO%2FGPS8LqhCBamQC6oo0560lEg%3D&reserved=0

Hi, accepted, with using -XLambdaCase. Thanks all! Cheers, Joachim Am Samstag, dem 18.09.2021 um 12:40 +0300 schrieb Vitaly Bragilevsky:

I've voted to extend LambdaCase. I prefer thinking that the backward incompatibility problem, in this case, is negligible.

Vitaly

пт, 17 сент. 2021 г. в 13:25, Simon Peyton Jones via ghc-steering- committee :

...

Vitaly, Tom Are you there?  I’d love to hear from you about this. Thanks Simon   PS: I am leaving Microsoft at the end of November 2021, at which pointsimonpj@microsoft.com will cease to work.  Usesimon.peytonjones@gmail.com instead.  (For now, it just forwards to simonpj@microsoft.com.)   From: Simon Peyton Jones Sent: 15 September 2021 13:00 To: ghc-steering-committee@haskell.org Cc: Simon Peyton Jones Subject: RE: [ghc-steering-committee] Proposal #302: Multiway lambda: new extension or not?   Vitaly, Eric, Tom, Alejandro As Joachim says, we need to make a decision on the LambdaCase flag issue.  It’s a judgement call, so let’s just vote. Here is the voting sheet.  I have filled in votes from Simon, myself, Joacim, Richard, Vlad.  But four of us (in the to: line) have not expressed an opinion. Could you do so please, in the next day or two?  It should take you 5 minutes. Thanks Simon         PS: I am leaving Microsoft at the end of November 2021, at which pointsimonpj@microsoft.com will cease to work.  Usesimon.peytonjones@gmail.com instead.  (For now, it just forwards tosimonpj@microsoft.com.)   |  -----Original Message----- |  From: ghc-steering-committee On Behalf Of Joachim Breitner |  Sent: 14 September 2021 08:39 |  To: ghc-steering-committee@haskell.org |  Subject: Re: [ghc-steering-committee] Proposal #302: Multiway lambda: |  new extension or not? |  |  Hi, |  |  |  on the multiway-lambda story, we have voted to add \cases alongside |  \case. But one open question is still: Do we |   (1) add -XLambdaCases (which would imply -XLambdaCase) or |   (2) simply expand the meaning of -XLambdaCase. |  |  On the Github thread at |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith |  ub.com%2Fghc-proposals%2Fghc- proposals%2Fpull%2F302%23issuecomment- |  895080031&data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a8831943 459 |  9cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376 720 |  20597687362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l uMz |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2ySitCA%2FT1uUzne zDY |  UKIO8g2ImLMKlnxm1OpKOXKZg%3D&reserved=0 |  we see that I lean towards (1), but SPJ leands towards (2). |  |  It doesn’t matter that much, but we need to make a decision. Can I |  please get some opinions from the rest of the committee on this point? |  |  Cheers, |  Joachim |  |  |  -- |  Joachim Breitner |    mail@joachim-breitner.de |  |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j |  oachim- |  breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a88 319 |  434599cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 C63 |  7672020597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj oiV |  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=unmdYu9zUy00 ec4 |  21KJYmL9I2ZO%2BlIx5J9cLw27GnmI%3D&reserved=0 |  |  |  _______________________________________________ |  ghc-steering-committee mailing list |  ghc-steering-committee@haskell.org |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail |  .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- |  committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cea35a8831943 459 |  9cce708d97752bd08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376 720 |  20597697367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l uMz |  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TG3t%2Fw1kFLk173S oM5 |  soHU39BlAPv76TY%2B9FNetaLJs%3D&reserved=0 _______________________________________________ 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/