[ghc-steering-committee] Proposal #302: Multiway lambda: time to vote
Simon Peyton Jones
simonpj at microsoft.com
Thu Jul 22 16:54:49 UTC 2021
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.
Simon
| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On
| Behalf Of Eric Seidel
| Sent: 22 July 2021 17:40
| To: ghc-steering-committee at haskell.org
| Subject: Re: [ghc-steering-committee] Proposal #302: Multiway lambda: time
| to vote
|
| 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.goog
| le.com%2Fdocument%2Fd%2F1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAIKnDs%2Fedit%
| 3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7C33056874189e46a
| d8d5e08d94d2f7635%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376256892630
| 44602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
| 1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=o9CBOSM1vWaTMRgQNLDtvUSZ6N9a7JYE4PJ2d%
| 2BAc5pM%3D&reserved=0>!
| > 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.goog
| le.com%2Fdocument%2Fd%2F1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAIKnDs%2Fedit%
| 3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7C5d7b8dd342144930392
| 308d9486d710b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63762045714140300
| 3%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
| wiLCJXVCI6Mn0%3D%7C1000&sdata=%2BAUVgyDZPoNjubavEBUhPYo5TGMRIfcPB5Q%2FQ5%2Bk
| K2Q%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
| > ub.com%2FJakobBruenker%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2F
| > 0000-lambda-layout.md&data=04%7C01%7Csimonpj%40microsoft.com%7C330
| > 56874189e46ad8d5e08d94d2f7635%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
| > C0%7C637625689263054559%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
| > JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5Cd%2FnJ
| > abIxYklNI7vnWZzIjD72%2BMnRYWvAzo7mgZ0Fk%3D&reserved=0
| > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
| > hub.com%2FJakobBruenker%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2
| > F0000-lambda-layout.md&data=04%7C01%7Csimonpj%40microsoft.com%7C4ae55d
| > 76732448a0c3a508d93a1955ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
| > 7C637604702751348160%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
| > joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Hvxpaew8S333OX7
| > IvW9cfD003mLSZxpjRdjOotGVZMA%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%7C33056874189e46ad8d5e08d94d2f7635%7C72f988bf
| > 86f141af91ab2d7cd011db47%7C1%7C0%7C637625689263054559%7CUnknown%7CTWFp
| > bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
| > 0%3D%7C3000&sdata=QUFXbh%2BZO0wyiZeHPkO46I2dFHJoFeAbxgDq5S3LhlU%3D
| > &reserved=0
| > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
| > hub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302&data=04%7C01%7Csi
| > monpj%40microsoft.com%7C4ae55d76732448a0c3a508d93a1955ed%7C72f988bf86f
| > 141af91ab2d7cd011db47%7C1%7C0%7C637604702751358154%7CUnknown%7CTWFpbGZ
| > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
| > D%7C1000&sdata=1aYsUzlUaixOxNvW2%2FEkLNbImFD7yLBT273QFA76ZEI%3D&reserv
| > ed=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://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%7C33056874189e46ad8d5e08d94d
| > 2f7635%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637625689263054559
| > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
| > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1xK4Ihtf6wnYuoQoIHYmGAmRS1aUnAY
| > uiopPd01PNwE%3D&reserved=0
| >
| _______________________________________________
| ghc-steering-committee mailing list
| ghc-steering-committee at 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%7C33056874189e46ad8d5e0
| 8d94d2f7635%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637625689263054559%
| 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
| LCJXVCI6Mn0%3D%7C3000&sdata=1xK4Ihtf6wnYuoQoIHYmGAmRS1aUnAYuiopPd01PNwE%
| 3D&reserved=0
More information about the ghc-steering-committee
mailing list