[ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ)

Thu Jun 24 15:26:36 UTC 2021

I don't have anything to add to the ballot. I'm in favour of the proposal,
and don't really have a preference between (1) and (4) (If \case didn't
exist I'd like (4) best, but I don't know how to orchestrate a transition)

On Thu, Jun 24, 2021 at 1:44 PM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> 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 <trupill at gmail.com>
> *Sent:* 24 June 2021 12:03
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* ghc-steering-committee at 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 <
> ghc-steering-committee at haskell.org> escribió:
>
> Dear Steering committee
>
> Simon and Joachim have responded, but only those two .  Please reply!
>
> 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
>
>    1. 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%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/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%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 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%7Cd5c0c59924fc488bc80108d936ffa123%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637601294485942171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VqSeULnnIImr6PUnxHTwFWkAqNntR7S3AWAq4ofmaD4%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210624/457af361/attachment.html>