Add LambdaCase proposal

[quchen]

Rendered version: https://github.com/quchen/rfcs/blob/lambdacase/texts/0000-lambdacase.rst

[strake]

I propose we merge this RFC as is. Any dissenters?

[gbaz]

So to make clear: if the proposal is merged, this moves from a discussion on whether the proposal should be added to the haskell report, to a phase where an actually delta against the haskell report is produced?

It seems according to the process the next step is for a Shepard to ensure that a discussion among prime committee members can reach a consensus here. (I personally think the proposal lgtm but I'm not on the prime committee so that doesn't count for much :-) ).

[goldfirere]

Drawback: You can't use \case to make an anonymous function with more than one argument.

That said, I still support inclusion in Haskell Prime.

[quchen]

@gbaz Probably yes, but I think if the discussion is lively and altogether in favour of the proposal, we don’t need to appoint a shepherd to guide through it. The shepherd is mostly for preventing the discussion from stalling or going off-topic too much, I would say.

[gbaz]

Sure. But what if the discussion is muted, but in favor? It still needs
someone to just "take it to the finish line" as it were (and e.g. volunteer
to draft the delta to the report or ensure that someone else does). If you
or M Farkas-Dyck want to take this on, that sound great to me :-).

On Thu, Aug 18, 2016 at 2:59 PM, David Luposchainsky <
notifications@github.com> wrote:

@gbaz https://github.com/gbaz Probably yes, but I think if the
discussion is lively and altogether in favour of the proposal, we don’t
need to appoint a shepherd to guide through it. The shepherd is mostly for
preventing the discussion from stalling or going off-topic too much, I
would say.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABEt2ZE8b2TCAywbXsfkTvdaqoY1vzqeks5qhKuTgaJpZM4JTUrf
.

[quchen]

@gbaz On second thought, maybe it’s not so bad if we try out the shepherd thing on a smaller issue.

[strake]

A drawback which comes to mind, actually, is the inability to match multiple arguments with this syntax. I think we ought to note this in the RFC.

[strake]

And now as i re-read this thread i see @goldfirere already brought this up, derp.

Anyhow, thanks for noting in RFC.

[quchen]

Added a note about the multiple argument shortcoming.

[yav]

People have suggested that a much more natural notation for LambdaCase is:

 case of { P1 -> e1; P2 -> e2 }

Thus LambdaCase may be explained simply as a "case section". Seems much nicer than the current syntax.

[strake]

@yav I agree it is nicer.

[spl]

Can you change the link in the opening comment to the final rendered proposal instead of the initial commit? That will help anybody (like me) coming late to the conversation.
https://github.com/quchen/rfcs/blob/lambdacase/texts/0000-lambdacase.rst

[spl]

In general, I think the drawbacks should be given more appreciation and exemplified and not given short shrift.

In particular, the paragraph starting with ”feature-wise, it is worth noting that lambda case does not support lambdas with multiple arguments well” says two things to me:

1. “Oh, by the way, there's this very minor issue that you don't need to worry about.” In other words, this paragraph is passing a judgment. I think one should make the statement, give an example, and leave the reader to judge the merits.
2. I'm not sure what it means to “support lambdas with multiple arguments well.” The “well” suggests the question “to what degree does it support lambdas with multiple arguments?” If the answer is that there is no degree – it either supports them or doesn't – then I think the “well” should be removed.

[blamario]

I have personally never used this extension, so I'm not sure if I should comment at all, but my impression is that it it's less mature than most of the others. The single-argument-only complaint has come up only recently, and I wouldn't be surprised if a superior alternative becomes available in a couple of years.

[jwiegley]

I use this extension fairly regularly, but I know there are many people who would prefer it in a different form. So, I agree it needs more research.

[JLimperg]

FYI, Agda uses the following syntaxes (the second having been introduced recently) for pattern matching lambdas:

toy toy' : ℕ → ℕ → Bool

toy = λ { zero (suc _) → true
        ; _    _       → false
        }

toy' = λ where
         zero (suc _) → true
         _    _       → false

These support multiple arguments, but in exchange, one has to put parens around constructors with arguments (even in the case where the lambda only takes one argument, which thus becomes slightly more cumbersome). Thus, the LHS of each case mirrors exactly the LHS of a top-level function definition.

[augustss]

This would be my preferred syntax.

…

On Wed, Oct 5, 2016 at 00:44 Iavor S. Diatchki ***@***.***> wrote: People have suggested that a much more natural notation for LambdaCase is: case of { P1 -> e1; P2 -> e2 } Thus LambdaCase may be explained simply as a "case section". Seems much nicer than the current syntax. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFAInjaaannphZvZnKPAkB5CWolKiOJEks5qwtatgaJpZM4JTUrf> .

[andreasabel]

After years of being supported by GHC, \case cannot be modified anymore. Too late for discussion on how it should have looked like instead.

If I need a binary anonymous pattern matching function, I write

f = uncurry $ \case
  (Cons x y, Foo z) -> bar
  ...

Writing tuples isn't super nice, but it isn't much longer than having to parenthesize each pattern, like in:

f = \cases
  (Cons x y) (Foo z) -> bar

I think adding \case to the standard is a no brainer now.

[jwiegley]

Having used this extension quite... extensively now, I realize that \case calls out to my mind that a lambda is being defined better than case of. For example:

forM_ xs $ \case
   ...

vs.

forM_ xs $ case of
  ...

Given how often the former is \i -> before being changed to \case, it shows its kinship with other lambdas a little better to the scanning eye.

[nhn1966]

Hi, Having used this extension quite... extensively now, I realize that \case calls out to my mind that a lambda is being defined better than case of. For example: forM_ xs $ \case ... vs. forM_ xs $ case of Given how often the former is \i -> before being changed to \case, it shows its kinship with other lambdas a little better to the scanning eye. For what it's worth, I've always found \case gratuitous and a syntactic aberration, and as to the above example, I find both (significantly) less clear than forM_ xs $ \x -> case x of ... As an (possibly somewhat flawed, but still) analogy, this is rather similar to [ case x of ... | x <- xs ] for which I hope I will never see an abbreviation proposal like [ case ... | xs ] In both cases (\case and this hypothetical list comprehension abbreviation) bring similar savings in typing (negligible) and similar increase in syntactic obscurity and additional syntax to learn. But I know lots of people swear by \case. I've just never been able to understand why. All the best, /Henrik ... This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

[yav]

I am with @nhn1966 on this one---I do quite a bit of Haskell development on a daily basis and I never use \case or find the need for it.