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

Simon Peyton Jones simonpj at microsoft.com
Mon Jul 19 09:53:19 UTC 2021


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 page<https://docs.google.com/document/d/1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAIKnDs/edit?usp=sharing> to reflect these observations.

Simon

From: Richard Eisenberg <lists at richarde.dev>
Sent: 17 July 2021 03:29
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-steering-committee at 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 <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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 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%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 <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Sent: 28 June 2021 10:45
To: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
Cc: Simon Peyton Jones <simonpj at microsoft.com<mailto: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<mailto: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<mailto:mail at joachim-breitner.de>>; ghc-steering-committee at haskell.org<mailto: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<mailto:ghc-steering-committee at 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=04%7C01%7Csimonpj%40microsoft.com%7C79a033bdb2344b4e79af08d948caac09%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637620858630921634%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1P8vKNf3KJPFYk2JGwu%2FUdBQTPDe%2Fc4yJG1yj%2Bc%2B1sU%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210719/2c361687/attachment-0001.html>


More information about the ghc-steering-committee mailing list