I think that would work pretty well. In fact, the implementation of such a rule would allow us to also point beginners when they need parentheses in regular pattern matching! El vie., 4 sept. 2020 a las 16:55, Richard Eisenberg () escribió:

Thinking about disambiguating \case Just x -> x: There is no way that \of Just x -> ... can be correct, because Just requires an argument. Very happily, the renamer's behavior is unaffected: any variables introduced are still binding sites. So, I think we could probably detect a case like this in the type-checker and either reinterpret it correct or provide a very helpful error message.

So here's a concrete idea:

- Change the existing proposal to use \case instead of \of. - Add a little magic to the type-checker, as specified below, to allow current usages of \case to be accepted. - When the magic triggers, issue a warning (-Wdeprecated-lambda-case, on by default). - Remove the magic (and its warning) in a few releases.

The magic: - The new construct allows many patterns before the -> where the old \case allowed only one. - The type-checker detects when the first of these patterns is a solitary constructor, and when this constructor is not nullary. - It then reconstructs the AST to move the remaining patterns as arguments of that first one. Because our AST tracks parens manually, the new AST will even print identically to the old one.

This magic is, well, magical, but it's well specified, backward compatible, and unambiguous.

What do we think?

Richard

On Sep 4, 2020, at 10:37 AM, Alejandro Serrano Mena wrote:

Hi all, I agree with the sentiment. I think adding \of would be a nice way to clean up the language (in the same way that now StandaloneKindSignatures allow us to remove the weirder CUSKs), but unless we have some deprecation policy for extensions, this may confuse people more than help.

It's particularly bad that we cannot make this simply an extension of \case, due to the example pointed out in the thread: \case Just x -> x. Could we maybe think of some way to disambiguate those cases? I'm going to ask this in the thread too.

Regards, Alejandro

El vie., 4 sept. 2020 a las 0:02, Richard Eisenberg () escribió:

...

Hi all,

Proposal #302 was submitted to the committee and assigned to Cale. He has made a recommendation on the GitHub trail, but I don't believe the committee has discussed this among ourselves.

PR: https://github.com/ghc-proposals/ghc-proposals/pull/302 Proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-l... Cale's recommendation: https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-6660750...

The idea, in brief, is to introduce a new syntax (guarded behind -XMultiWayLambda) \of. Here is an example, which gives you the idea:

mplus :: Maybe Int -> Maybe Int -> Maybe Int mplus = \of Nothing _ -> Nothing _ Nothing -> Nothing (Just x) (Just y) -> Just (x + y)

The new keyword allows us to use a syntax similar to function definitions, but without repeating the name of the function. It is also like \case, but it allows multiple arguments. Guards are allowed, as usual.

I really like this new syntax -- mostly because I find it very strange that we have to repeat the function name on every line. And then change the spacing when we change the function name. And I like the mnemonic "lambda of". And it allows me to write a where clause that is accessible in multiple different patterns, or an indented where clause that is usable in just one. If it didn't confuse readers, I would use this syntax all the time.

Even so, I agree with Cale's recommendation to reject. We just have too much syntax! If someone were to come along and draft a concrete proposal of how we could, for example, use this syntax to replace both \case and if|, with a migration strategy, etc., then I might be in favor. Until then, I think we've spent our budget for cute, obscure bits of syntax.

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

I am broadly supportive of this issue. I do find the `of` keyword rather off-putting. But I could live with it. Many variations are being mooted on the github thread, I don't really have an opinion among all of these yet. On Fri, Sep 4, 2020 at 6:04 PM Iavor Diatchki wrote:

I am not sure what problem we are solving, and I doubt this would lead to more readable Haskell, or more streamlined language definition. So what's the gain?

On Fri, Sep 4, 2020 at 7:57 AM Alejandro Serrano Mena wrote:

...

I think that would work pretty well. In fact, the implementation of such a rule would allow us to also point beginners when they need parentheses in regular pattern matching!

El vie., 4 sept. 2020 a las 16:55, Richard Eisenberg () escribió:

...

Thinking about disambiguating \case Just x -> x: There is no way that \of Just x -> ... can be correct, because Just requires an argument. Very happily, the renamer's behavior is unaffected: any variables introduced are still binding sites. So, I think we could probably detect a case like this in the type-checker and either reinterpret it correct or provide a very helpful error message.

So here's a concrete idea:

- Change the existing proposal to use \case instead of \of. - Add a little magic to the type-checker, as specified below, to allow current usages of \case to be accepted. - When the magic triggers, issue a warning (-Wdeprecated-lambda-case, on by default). - Remove the magic (and its warning) in a few releases.

The magic: - The new construct allows many patterns before the -> where the old \case allowed only one. - The type-checker detects when the first of these patterns is a solitary constructor, and when this constructor is not nullary. - It then reconstructs the AST to move the remaining patterns as arguments of that first one. Because our AST tracks parens manually, the new AST will even print identically to the old one.

This magic is, well, magical, but it's well specified, backward compatible, and unambiguous.

What do we think?

Richard

On Sep 4, 2020, at 10:37 AM, Alejandro Serrano Mena wrote:

Hi all, I agree with the sentiment. I think adding \of would be a nice way to clean up the language (in the same way that now StandaloneKindSignatures allow us to remove the weirder CUSKs), but unless we have some deprecation policy for extensions, this may confuse people more than help.

It's particularly bad that we cannot make this simply an extension of \case, due to the example pointed out in the thread: \case Just x -> x. Could we maybe think of some way to disambiguate those cases? I'm going to ask this in the thread too.

Regards, Alejandro

El vie., 4 sept. 2020 a las 0:02, Richard Eisenberg () escribió:

...

Hi all,

Proposal #302 was submitted to the committee and assigned to Cale. He has made a recommendation on the GitHub trail, but I don't believe the committee has discussed this among ourselves.

PR: https://github.com/ghc-proposals/ghc-proposals/pull/302 Proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-l... Cale's recommendation: https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-6660750...

The idea, in brief, is to introduce a new syntax (guarded behind -XMultiWayLambda) \of. Here is an example, which gives you the idea:

mplus :: Maybe Int -> Maybe Int -> Maybe Int mplus = \of Nothing _ -> Nothing _ Nothing -> Nothing (Just x) (Just y) -> Just (x + y)

The new keyword allows us to use a syntax similar to function definitions, but without repeating the name of the function. It is also like \case, but it allows multiple arguments. Guards are allowed, as usual.

I really like this new syntax -- mostly because I find it very strange that we have to repeat the function name on every line. And then change the spacing when we change the function name. And I like the mnemonic "lambda of". And it allows me to write a where clause that is accessible in multiple different patterns, or an indented where clause that is usable in just one. If it didn't confuse readers, I would use this syntax all the time.

Even so, I agree with Cale's recommendation to reject. We just have too much syntax! If someone were to come along and draft a concrete proposal of how we could, for example, use this syntax to replace both \case and if|, with a migration strategy, etc., then I might be in favor. Until then, I think we've spent our budget for cute, obscure bits of syntax.

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

If it was re-cast as \mcase, which is just like \case but allows n-ary functions, I’d find it quite acceptable. The two then become extremely close, so there’s a very low cognitive load. GHC’s internals already allow this, and it seems surprisingly non-orthogonal that the source language does not. We could kill off MultiWayIf. But I don’t feel strongly. If a consensus does not emerge, maybe we should just vote. Simon From: ghc-steering-committee On Behalf Of Simon Marlow Sent: 17 September 2020 15:53 To: Richard Eisenberg Cc: Simon Peyton Jones via ghc-steering-committee Subject: Re: [ghc-steering-committee] Proposal #302: `\of` Cale's rationale chimes with me. A lot - I feel like I might have even made the same point in previous threads on this. I think of the tradeoff like this: * The lack of \of doesn't really hurt very much. In fact, arguably by forcing the author to type some more characters and give something a name, we get code that's clearer for the reader. (yes this is very subjective, but syntax is). * The addition of \of *would* hurt new users of the language. Only a bit, but every bit makes things worse, and things are already quite bad. Cheers Simon On Thu, 3 Sep 2020 at 23:02, Richard Eisenberg mailto:rae@richarde.dev> wrote: Hi all, Proposal #302 was submitted to the committee and assigned to Cale. He has made a recommendation on the GitHub trail, but I don't believe the committee has discussed this among ourselves. PR: 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=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199745852&sdata=dTBwWAv4oSLAVZXcCimFWfeNygnz%2FKcadcWw0YNdcuk%3D&reserved=0 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=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199755846&sdata=MusKqbiaRHp2rbPuyFQTYYiSP9%2FjGkwKKmPoPwRu1qc%3D&reserved=0 Cale's recommendation: https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-6660750...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-666075014&data=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199755846&sdata=MiDN5T22uVYITKYiB3yyyqrhe%2FleEKLvJk%2FjnaiVI7Y%3D&reserved=0 The idea, in brief, is to introduce a new syntax (guarded behind -XMultiWayLambda) \of. Here is an example, which gives you the idea: mplus :: Maybe Int -> Maybe Int -> Maybe Int mplus = \of Nothing _ -> Nothing _ Nothing -> Nothing (Just x) (Just y) -> Just (x + y) The new keyword allows us to use a syntax similar to function definitions, but without repeating the name of the function. It is also like \case, but it allows multiple arguments. Guards are allowed, as usual. I really like this new syntax -- mostly because I find it very strange that we have to repeat the function name on every line. And then change the spacing when we change the function name. And I like the mnemonic "lambda of". And it allows me to write a where clause that is accessible in multiple different patterns, or an indented where clause that is usable in just one. If it didn't confuse readers, I would use this syntax all the time. Even so, I agree with Cale's recommendation to reject. We just have too much syntax! If someone were to come along and draft a concrete proposal of how we could, for example, use this syntax to replace both \case and if|, with a migration strategy, etc., then I might be in favor. Until then, I think we've spent our budget for cute, obscure bits of syntax. Richard _______________________________________________ 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=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199765841&sdata=zraLb1BkWyd7RIDmN7GR%2B5IUJwzbetShFqcsp4RwLGQ%3D&reserved=0

I use MultiWayIf occasionally, but I would probably not use it at all if I had to type "\mcase" rather than "if". I mean, that just feels too obscure and ugly - yes it's kind of cute that it falls out as the degenerate case of zero arguments, but I find it strange that I could write something that looks like a lambda and not get a lambda, and "mcase" is just obscure-sounding. I probably wouldn't object all that much to getting rid of MultiWayIf, it might not be paying its way, but I'm not convinced that \mcase or \of would pay their way either. Cheers Simon On Thu, 17 Sep 2020 at 16:22, Simon Peyton Jones wrote:

If it was re-cast as \mcase, which is just like \case but allows n-ary functions, I’d find it quite acceptable. The two then become extremely close, so there’s a very low cognitive load.

GHC’s internals already allow this, and it seems surprisingly non-orthogonal that the source language does not.

We could kill off MultiWayIf.

But I don’t feel strongly. If a consensus does not emerge, maybe we should just vote.

Simon

*From:* ghc-steering-committee *On Behalf Of *Simon Marlow *Sent:* 17 September 2020 15:53 *To:* Richard Eisenberg *Cc:* Simon Peyton Jones via ghc-steering-committee < ghc-steering-committee@haskell.org> *Subject:* Re: [ghc-steering-committee] Proposal #302: `\of`

Cale's rationale chimes with me. A lot - I feel like I might have even made the same point in previous threads on this. I think of the tradeoff like this:

* The lack of \of doesn't really hurt very much. In fact, arguably by forcing the author to type some more characters and give something a name, we get code that's clearer for the reader. (yes this is very subjective, but syntax is).

* The addition of \of *would* hurt new users of the language. Only a bit, but every bit makes things worse, and things are already quite bad.

Cheers

Simon

On Thu, 3 Sep 2020 at 23:02, Richard Eisenberg wrote:

Hi all,

Proposal #302 was submitted to the committee and assigned to Cale. He has made a recommendation on the GitHub trail, but I don't believe the committee has discussed this among ourselves.

PR: 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=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199745852&sdata=dTBwWAv4oSLAVZXcCimFWfeNygnz%2FKcadcWw0YNdcuk%3D&reserved=0 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=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199755846&sdata=MusKqbiaRHp2rbPuyFQTYYiSP9%2FjGkwKKmPoPwRu1qc%3D&reserved=0 Cale's recommendation: https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-6660750... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302%23issuecomment-666075014&data=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199755846&sdata=MiDN5T22uVYITKYiB3yyyqrhe%2FleEKLvJk%2FjnaiVI7Y%3D&reserved=0

The idea, in brief, is to introduce a new syntax (guarded behind -XMultiWayLambda) \of. Here is an example, which gives you the idea:

mplus :: Maybe Int -> Maybe Int -> Maybe Int mplus = \of Nothing _ -> Nothing _ Nothing -> Nothing (Just x) (Just y) -> Just (x + y)

The new keyword allows us to use a syntax similar to function definitions, but without repeating the name of the function. It is also like \case, but it allows multiple arguments. Guards are allowed, as usual.

I really like this new syntax -- mostly because I find it very strange that we have to repeat the function name on every line. And then change the spacing when we change the function name. And I like the mnemonic "lambda of". And it allows me to write a where clause that is accessible in multiple different patterns, or an indented where clause that is usable in just one. If it didn't confuse readers, I would use this syntax all the time.

Even so, I agree with Cale's recommendation to reject. We just have too much syntax! If someone were to come along and draft a concrete proposal of how we could, for example, use this syntax to replace both \case and if|, with a migration strategy, etc., then I might be in favor. Until then, I think we've spent our budget for cute, obscure bits of syntax.

Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C956b41eaa3984a4a739d08d85b197bb4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637359513199765841&sdata=zraLb1BkWyd7RIDmN7GR%2B5IUJwzbetShFqcsp4RwLGQ%3D&reserved=0

Hi, Am Dienstag, den 27.10.2020, 18:52 +0100 schrieb Joachim Breitner:

Am Donnerstag, den 17.09.2020, 15:22 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:

...

If it was re-cast as \mcase, which is just like \case but allows n- ary functions, I’d find it quite acceptable. The two then become extremely close, so there’s a very low cognitive load.

GHC’s internals already allow this, and it seems surprisingly non- orthogonal that the source language does not.

We could kill off MultiWayIf.

But I don’t feel strongly. If a consensus does not emerge, maybe we should just vote.

Cale, as the shepherd, could you lead us here to a resolution? I see many voices in favor of rejection, but not really consensus yet.

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? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Hi, thanks for narrowing down the option, I am happy with direction, and have nothing urgent to add. Option (3), XExtendedCase, is in a way cute, but probably too playful for its own good. I think (1) is a good way forward, and balances elegance with backward compatibility (by not conflicting with the popular \case) well. We can have some fun coming up with the right name (\cases? \of? \mcase? \function?). My solution to avoid spending too much time on that particular bike shed color is just to include all reasonable variants on the ballot and let ranked voting sort it out for us. Cheers, Joachim Am Dienstag, den 15.06.2021, 12:52 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:

I think we’ll end up having to vote on this, which is fine when it’s a judgement call about syntax. But first: -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Dear Steering committee Simon and Joachim have responded, but only those two . Please reply! 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%7C0903e8fd7cbe4aadc88b08d92ffc71d2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637593584027236069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=DNZOpilyGrWdTDQyaqEgf1orDNQNX9ZwbMwmGYAk64g%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%7C0903e8fd7cbe4aadc88b08d92ffc71d2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637593584027246062%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=LXuEVBuMxQlbF0elOS2792K5avMW3SeIYEuEDyyFmmo%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

I think \cases could completely replace \if. Just replace \if with \cases. Am I wrong about that? If it could replace it, then deprecating \if in favour of \cases would make sense. I'm very relaxed about having both \case and \cases, because they do not require any extra mental scaffolding or complication. \cases always works; you can use \case if there is one argument and you don't want to write those extra parens (as indeed you don't in case). Simon From: Alejandro Serrano Mena Sent: 24 June 2021 12:03 To: Simon Peyton Jones Cc: ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ) Dear all, To be honest, I'm still trying to make up my mind about this. If we were to accept the proposal, I think option (1) is the best one, since it otherwise `\case` would have a different behaviour depending on whether you have -XLambdaCase or -XExtendedLambdaCase on. Having said so, the words of Simon M. and Richard resonate with me: do we really want \case, \cases, if|, all in the language? - I would prefer one single way to do stuff, let's say having a `cases ... of` which also works as case, if|... and then a \cases for lambdas; - but this is not the world we live in! We already have those things, and this would be yet another small syntactic addition, so we need to think about whether the language is becoming too big. So right now I'm in favor of option (X), reject the proposal. Regards, Alejandro El 24 jun 2021 12:52:10, Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> escribió: Dear Steering committee Simon and Joachim have responded, but only those two . Please reply! 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 1. 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%7Cd5c0c59924fc488bc80108d936ffa123%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637601294485922203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eRU47RcIzCunA6uxy7Q5D8PLXoelL1eKNfavFK3kIS8%3D&reserved=0 2. 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%7Cd5c0c59924fc488bc80108d936ffa123%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637601294485932182%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yz8M6OjNgzFNDiaT2JeLonmuDyXaFXJJseMwA9ZCsLQ%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%7Cd5c0c59924fc488bc80108d936ffa123%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637601294485942171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VqSeULnnIImr6PUnxHTwFWkAqNntR7S3AWAq4ofmaD4%3D&reserved=0

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%7C0903e8fd7cbe4aadc88b08d92ffc71d2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637593584027236069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=DNZOpilyGrWdTDQyaqEgf1orDNQNX9ZwbMwmGYAk64g%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%7C0903e8fd7cbe4aadc88b08d92ffc71d2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637593584027246062%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=LXuEVBuMxQlbF0elOS2792K5avMW3SeIYEuEDyyFmmo%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

Thanks Vlad. Personally I don't see this as a problem, but my question was only: | > * Are there any other alternatives you strongly want on the ballot? I believe you may be saying that you'd like (2) or maybe (3) or maybe both on the ballot as well? Or perhaps some other alternative? Let me know what you'd like. Then we can proceed to voting on them. But the first thing is to have some clearly-stated alternatives on which to vote. Thanks Simon | -----Original Message----- | From: Vladislav Zavialov (int-index) | Sent: 28 June 2021 11:20 | To: Simon Peyton Jones | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: | Simon PJ) | | There's major flaw in options (1) and (4). Consider: | | \cases | X a -> | -- very long | -- rhs | -- that takes | -- several lines | Y b -> ... | | By the time I get to the `Y b -> ...` alternative, I may have forgotten if | it's \case or \cases, so I won't know whether to (mentally) parse it as two | patterns `Y` `b`, or a single pattern `Y b`. | | Option (2) solves this with commas: | | \cases | X, a -> ... | Y, b -> ... | | Option (3) solves this with a lambda: | | case of | \X a -> ... | \Y b -> ... | | So in both (2) and (3) there's a clear syntactic indication that parsing | this alternative differs from normal, unary \case and case of. | | Unfortunately, Simon discarded both of these from the vote! So I'm currently | leaning towards rejecting the proposal, since I can't vote for the options | that look reasonable to me. | | - Vlad | | | > On 28 Jun 2021, at 12:44, Simon Peyton Jones via ghc-steering-committee | wrote: | > | > 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://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%7C11e2548cef584a4816480 | 8d93a1e3b84%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637604724423195072% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=riZXAyQbv1LLzbiHbPPIPMnXzrFOhtMeuH2SfIje8ls% | 3D&reserved=0 | > * Here is the discussion: | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | > ub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302&data=04%7C01%7 | > Csimonpj%40microsoft.com%7C11e2548cef584a48164808d93a1e3b84%7C72f988bf | > 86f141af91ab2d7cd011db47%7C1%7C0%7C637604724423195072%7CUnknown%7CTWFp | > bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn | > 0%3D%7C3000&sdata=PqnR%2BWM9RDQkrWCk4ItoZYZMl2z1tCPlVqbG8y2lL70%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | > .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&a | > mp;data=04%7C01%7Csimonpj%40microsoft.com%7C11e2548cef584a48164808d93a | > 1e3b84%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637604724423195072 | > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I | > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1QO9LR43LzG3TELp2guWxCH9B0Fqm8v | > HB%2FgadoRTwQg%3D&reserved=0

Thanks. Which one? Or do you want both? Simon | -----Original Message----- | From: Vladislav Zavialov (int-index) | Sent: 28 June 2021 12:27 | To: Simon Peyton Jones | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: | Simon PJ) | | Yes, I find (2) and (3) to be the superior options, so it’d be nice to have | at least one of those on the ballot. | | - Vlad | | > On 28 Jun 2021, at 13:55, Simon Peyton Jones | wrote: | > | > Thanks Vlad. Personally I don't see this as a problem, but my question was | only: | > | > | > * Are there any other alternatives you strongly want on the | ballot? | > | > I believe you may be saying that you'd like (2) or maybe (3) or maybe both | on the ballot as well? Or perhaps some other alternative? | > | > Let me know what you'd like. Then we can proceed to voting on them. But | the first thing is to have some clearly-stated alternatives on which to | vote. | > | > Thanks | > | > Simon

Got it thanks. Awaiting input from Vitaly, Tom, Eric, Richard. Simon | -----Original Message----- | From: Vladislav Zavialov (int-index) | Sent: 28 June 2021 16:25 | To: Simon Peyton Jones | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: | Simon PJ) | | While (3) is my personal favorite, it has received some heavy pushback, and | I don’t suppose it has any chance of getting accepted. Therefore, I guess | I’m asking to add (2). | | - Vlad | | > On 28 Jun 2021, at 14:50, Simon Peyton Jones | wrote: | > | > Thanks. Which one? Or do you want both? | > | > Simon

I would like (2) to be on the ballot as well. It's unclear from the proposal whether (2) includes the extension to `case of` or if it's a hypothetical future extension, but I think the extension to `case of` should be included. On Tue, Jun 29, 2021, at 18:03, Richard Eisenberg wrote:

I don't need any further options, but I'm happy for (2) to be on the ballot.

Thanks, Richard

...

On Jun 29, 2021, at 4:59 AM, Simon Peyton Jones via ghc-steering-committee wrote:

Got it thanks.

Awaiting input from Vitaly, Tom, Eric, Richard.

Simon

| -----Original Message----- | From: Vladislav Zavialov (int-index) | Sent: 28 June 2021 16:25 | To: Simon Peyton Jones | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: | Simon PJ) | | While (3) is my personal favorite, it has received some heavy pushback, and | I don’t suppose it has any chance of getting accepted. Therefore, I guess | I’m asking to add (2). | | - Vlad | | > On 28 Jun 2021, at 14:50, Simon Peyton Jones | wrote: | > | > Thanks. Which one? Or do you want both? | > | > 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

Hi, Am Montag, dem 28.06.2021 um 18:25 +0300 schrieb Vladislav Zavialov (int-index):

While (3) is my personal favorite, it has received some heavy pushback, and I don’t suppose it has any chance of getting accepted. Therefore, I guess I’m asking to add (2)

we do ranked voting precisely to not have to spend time on such discussions. Including an option with little chance doesn’t affect the outcome, so just include it. And even a single member saying it’s their personal favorite is, IMHO, enough reason to include it on the ballot. Also, realistically, not all the committee members have probably made up their mind, and some will only look careful at whatever is on the ballet. So we can’t know whether it s has a chance until it is voted on. It’s also nice to all the people outside the committee who might favor this option to include it. TL;DR: Don't be stingy with the options :-) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/