[ghc-steering-committee] Proposal #302: Multiway lambda: time to vote

Thu Jul 22 16:40:07 UTC 2021

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_Qe1vacAIKnDs/edit?usp=sharing>!
> Thanks
> Simon
>  
> *From:* Simon Peyton Jones <simonpj at microsoft.com> 
> *Sent:* 16 July 2021 16:22
> *To:* ghc-steering-committee at haskell.org
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>
> *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 <simonpj at microsoft.com> 
> *Sent:* 28 June 2021 10:45
> *To:* ghc-steering-committee at haskell.org
> *Cc:* Simon Peyton Jones <simonpj at 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 
> <ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Simon 
> Peyton Jones via ghc-steering-committee
> *Sent:* 15 June 2021 13:52
> *To:* Joachim Breitner <mail at joachim-breitner.de>; 
> ghc-steering-committee at 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-lambda-layout.md <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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 