Compiler: Feature Request: Steal case lambda's from scala

[Fresheyeball]

(sorry for making more requests, Elm has been inspiring me lately).

Ok, so Scala has the ability to pattern match in a point free way.

b map({
    case Some(1) => "one"
    case Some(_) => "num" 
    case None => "nope" })

Scala just fills in the match statement for you. Which is a rather nice thing, compared to the alternative of having a one usage variable just to pattern match

b map(x => x match {
    case Some(1) => "one"
    case Some(_) => "num" 
    case None => "nope" })

Perhaps something Elm could use this idea.

List.map (\x -> case x of 
  Just 1 -> "one"
  Just _ -> "num"
  Nothing -> "nope") b                              

could become, or something else along these lines

List.map (case
  Just 1 -> "one"
  Just _ -> "num"
  Nothing -> "nope") b                              

[process-bot]

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

[mgold]

It's a clever idea, but I'm opposed based on the "there's only one way to do it" principle. I'd need to see some real code where this syntax makes a dramatic positive difference.

[evancz]

I agree with @mgold.

I also think having a bunch of feature requests on this issue is not ideal. I read what's going on with elm-dev and I am familiar with this syntax idea from the Haskell version. Expressing-things-you-can-already-express is very low on my priority list, so I do not expect to revisit this for quite a while.

[mandrolic]

Was about to raise this as a feature request until I found this issue. Shame it has been discounted as I use it a lot in F# (where it's called 'function') and find it results in clearer code in a lot of cases.

I can totally understand deferring implementing it on a the basis of priorities, however the 'One way to do things' argument holds no water. If it did, there would be no call for the |> operator, [1..4], .foo etc

[mgold]

[1..4] is being removed for this reason. The |> operator has been shown to improve real-world code.

[mandrolic]

The |> operator has been shown to improve real-world code.

I know. That's why I mentioned it. It clearly proves that the "there's only one way to do it" principle is invalid.

[Fresheyeball]

@mandrolic that is a great point and something I didnt see until you pointed it out. Both of the pipe operators, as well as composition, and point free style, ALL violate the "one way" design principle, yet are core to Elm and improve real world code.

[mgold]

An even more basic example:

f x = ...
f = \x -> ...

-- or even

\x y -> ..
\x -> \y -> ...

The real principle, which I articulated only imperfectly in my June 19 comment, is: _There should be one way to do it, unless another way greatly improves real-world code._ In practice, the "first" way will typically be a primitive, like nested lambdas or deeply nested parens.

[mandrolic]

Not buying it. There is no such principal, otherwise this would not be in Elm

List.Map .bar foos

The 'great improvement' of the record getter function is _the same_ as the lambda case proposed in this issue - removing the noise of the lambda.
So the notion that there is a principal at work in service of duplication removal can be dropped. It is just a simple case of whether any particular language feature is 'worth' having, as you say qualified by the assessment of how it 'improves' the code. Naturally this is a matter of opinion, I can see your opinion is that you would rather have less features in the language and more lambdas in your code, but there are evidently others who disagree with your opinion.

[mgold]

Okay, try this on: .bar doesn't look like any other language feature. But "case-as-lambda" would be confusing: "Do I need x of after the case or not? What's the difference?"

[mandrolic]

Same argument as: 'x.foobar' vs '.foobar' - do I need the x or not? Answer is whether you need a function, or not. It's not guess work, and not particularly more confusing than anything else in a terse functional language.
But if extra distinctness is desired then the F# approach of introducing a new keyword could be taken ('match/with' vs 'function'). Though I don't find F#'s choice of 'function' a particularly good choice as it is hard Google and get results pertaining to pattern matching functions.

[marcotoniut]

I knew I would find an issue addressing the lambda case I miss so much from Haskell. Hopefully there's intention to reconsider this pattern as it makes code much more concise by getting rid of unnecessary variables; I'd be willing to put time into the implementation if it so were.

[dullbananas]

If this is implemented, the existing syntax should be replaced:

-- old
case x + 1 of
    -- ...

-- new
x + 1 |> case
    -- ...

[marcotoniut]

The Lambda Case extension in Haskell allows you to take the following code:

\x -> case x of
  A -> 1
  B -> 2

and turn it into:

\case
  A -> 1
  B -> 2

No need to even name the variable. To me, it looks like a perfect fit for something like Elm. Unless there is some conflict with the syntax that I'm unaware of.

[PixelPartner]

I'm happy to not know Haskel, nor F#, looking at this discussion.
The rare cases needing a single variable in a case of wouldn't make me use such special syntax.
My 2 cents.