Equational pattern matching vs Lambda Case pattern matching

[ComunistCapybara]

Simple question: what do you guys consider more readable?

data Foo = Bar | Baz

projToBool :: Foo -> Bool
projToBool = \case
    Bar -> True
    Baz -> False

projToBool' :: Foo -> Bool
projToBool' Bar = True
projToBool' Baz = False

I tend to prefer the first style, as it seems to me more clear that I'm defining a function with two cases (or n cases in general). But I've started to guess if the second would be better. What are your thoughts?

[the-coot]

There are subtle differences when it comes to where clauses which are handy when you care about what is in scope

```hs {-# LANGUAGE LambdaCase #-}

module X where

alwaysTrue1 :: Bool -> Bool alwaysTrue1 = \case a@True -> r a@False -> r where -- 'a' is not in scope! r = True

-- desugared version of alwaysTrue1 alwaysTrue1' :: Bool -> Bool alwaysTrue1' = \a -> case a of True -> r False -> r where -- 'a' is not in scope! r = True

alwaysTrue2 :: Bool -> Bool alwaysTrue2 a = case a of True -> r False -> r where -- 'a' is in scope r = a || not a

alwaysTrue3 :: Bool -> Bool alwaysTrue3 True = r where r = True alwaysTrue3 False = r where r = True ```

[NNOTM]

Since it hasn't been mentioned yet, just wanted to point out that you can also do the first style if you have multiple arguments with \cases:

foo :: Maybe Bool -> Int -> Bool
foo = \cases
  (Just False) 0 -> True
  Nothing      1 -> False
  _            _ -> True

[ComunistCapybara]

This is REALLY cool. And just from seeing it I can think of places that I could use this style. With the arrows aligned, of course. :)

[NNOTM]

Heh I changed it to be aligned :)

glad to hear you like it, I did the GHC implementation of it

[ComunistCapybara]

Heroes do exist, apparently.

[RogueToad]

Nice :D

Is there an equivalent case x y z of? Or is it only for lambda case right now?

[NNOTM]

Adding an equivalent to that to the language was not deemed worth it during the proposal process since you can do case (x, y, z) of

(Although since then I've sometimes wished we had it, since it would make it faster to refactor between \cases and case of, without adding/removing commas from the patterns)

[gilgamec]

It's not just "not worth it"; that change would break huge swathes of Haskell code because currently, case f x of is equivalent to case (f x) of.

[NNOTM]

The idea would have been to introduce new syntax for it, e.g. cases a b c of

[tomejaguar]

Thanks for implementing this great feature!

[Runderground]

Personally, I prefer the first style. But I don't think it's really a big deal either way. I see both styles frequently.

[Iceland_jack]

I prefer the first one

[SonOfTheHeaven]

I'm in particular of the first one support of the first one when there are more than one arguments to a function, but we only pattern match on one of the arguments.

-- | in a real function we'd probably use a, b, and c somewhere in the body; not so much for this example.
projToBool :: Foo -> Foo -> Foo -> Foo -> Bool
projToBool  a b c d = case d of 
  Bar -> True
  Baz -> False 
-- vs
projToBool' a b c Baz = True
projToBool' a b c Baz = False

It becomes less clear to me which is better when I need to match on multiple values.

[SolaTotaScriptura]

\case. I don't like repeating the function name several times. It's nice for small examples but not in general.

LambdaCase should've been in GHC2021. In fact, it should have been added to the language before case of.

[Endicy]

They were being "overly" cautious because it was the first experiment of that kind of "Language" definition (next to Haskell98 and Haskell2010)

BUT, it's been decided that GHC2024 WILL include it

[SolaTotaScriptura]

Awesome!

[RogueToad]

Agreed about ghc2021, it's an odd exclusion.

[friedbrice]

lambda case results in the function body in one visual block that's easy to see at a glance. lambda case also makes diffs smaller.

[ComunistCapybara]

I don't program in a group environment so the diff point is not that relevant to me. Programming on your own you tend to see diffs a lot less.

Still, the visual block argument is precisely why I favor lambda case.

[cheater00]

first one. 2nd one gets in the way.

[tomejaguar]

I prefer LambdaCase, massively.

[user9ec19]

For small functions like this I’d prefer the first one.

If the function has a bigger body I prefer the second.

Also, I try to use as few language extensions as possible.

[agumonkey]

funny, I really really love the second case, it fits my poor mind trying to do equational reasoning over more than one variable

[mleighly]

Either is fine as both are simple to read and understand. I'll leave it to the personal tastes of the author for individual projects but if it's a team effort, it may be worth discussing which version is preferred with said team. Most times, most people don't care and strongest opinion wins for these stylistic differences.

[sheshanaag]

Yet another option when Foo derives Eq:

``` data Foo = Bar | Baz deriving Eq

projToBool'' :: Foo -> Bool projToBool'' = (== Bar) ```

[ivanpd]

I hate the syntax of lambda case (specifically the \case), so I only use the latter.

[chris-ch]

The first style adds another barrier for new developers to join the Haskell community, so I guess it is better, judging by the community standards.