Case _ of > function pattern

#1

I have noticed that I am using

functionName = case _ of
  SomeConstructor _ -> something
  SomeOtherConstructor _ _ -> somethingElse

far more than

functionName (SomeConstructor _) = something
functionName (SomeOtherConstructor _ _) = somethingElse

because it saves a lot of line space and no parentheses mucking things up.

However this seems to be defeating the point of how function pattern matching was supposed to be. I am sure that a lot of thought has gone into this but I still find it a bit annoying.

It seems like with function pattern matching with a single input it would be possible to

functionName
  SomeConstructor _ = something
  SomeOtherConstructor _ _ = somethingElse

Any thoughts on this?

2 Likes
#2

case _ of came after equation-style function definitions. I also almost exclusively use case _ of.

4 Likes
#3

I’m not familiar with the parser, but I would guess your proposed syntax would needlessly complicate it…?

#4

I agree with @garyb. We’ve banned equational style from our codebase.

#5

Since “equational style” seems to be a wart that is already being banned it seems like there is an opportunity to deprecate it for a case _ of like syntax.

It doesn’t seem worth having equivalent conflicting function syntax that causes JavaScriptesque flame wars.

#6

I realised there’s an exception to my case _ of usage: I’d never use that for a single-constructor pattern match.

2 Likes
#7

Yeah, I should say we’ve banned equational style with multiple branches. We will definitely unwrap newtypes this way.

1 Like
#8

I agree too, I rarely use patterns such that I’m writing out a function name more than once. That said, I’m really not keen on deprecating this - let’s be honest, it isn’t causing any JavaScript style flame wars now, but lots of people will rightly be very annoyed if they have to rewrite a whole bunch of perfectly fine code as a result of this being deprecated. I think I’ve said in a few different places now: there is clearly a strong appetite in the community for language stability and at this point in the language’s development we should only be making breaking changes when they are really needed.

5 Likes
#9

I agree, I don’t see a need to deprecate anything. It’s just basic sugar, so it’s not really doing any harm, except to the wrists of people who decide to use it!

#10

Yeah, I should say we’ve banned equational style with multiple branches. We will definitely unwrap newtypes this way.

This is what Elm enforces. Anyway, I personally like the choice in pure-script and even though I also personally tend to use case of more I don’t think it will be a good idea to enforce it. From my experience, there are enough Haskell developers who prefer equation-style. I also remember I’ve talked with a guy at a conference who was complaining that elm doesn’t support this. So unless there is a good reason why to deprecate it I don’t think it’s worth the hassle.

1 Like
#11

Is this feature/pattern defined in any Purescript guide/reference? I’ve came across it only in code examples. Also, does it have a name (eg. “default case expressions”)?

#12

There is mention of Wildcards here, but you are correct that there is no mention of Wildcards in general. Perhaps you could create a section for Wildcards.

#13

AFAIK, I cover all of PureScript’s syntax in my learning repo’s Syntax folder. Specifically, I cover it here, but I don’t know whether it’s named.

@BebeSparkelSparkel Record wildcards are also covered in my repo here

1 Like
#14

Just adding a mention for this wildcards in case expressions in this page would already be something (and maybe even defining a name for it)… What do you think?

#15

There is already a haskell name for this lambda-case. I think this is another reason that there is not much documentation for case _ of since many already expect it to exist.

#16

I didn’t know about this! In any case, this syntax is slightly different from the case _ of in Purescript, or am I mistaken?

#17

Haskell: \case
PureScript: case _ of

1 Like
#18

Just to offer an opposite point of view, I love equational style and pattern matching on function arguments. I am a heavy user of F# (besides both Haskell and PureScript) and miss equational definitions in F# very much.

Just for amusement and regarding the case _ of pattern, F# has a nice syntax using a specific keyword function for matching on the last argument of a function without introducing a formal parameter:

let f = function
  | Something -> expr1
  | SomethingElse -> expr2

It works also in this form (convoluted example):

let sum a = function
  | 0 -> a
  | b -> a + b

And inline:

let a = expression |> (function | Some a -> a | None -> 0)
1 Like
#19

I like that function is a single word and in vim I can just c-n that instead of writing 3 separate words.