In the tutorial section on pattern matching, this snippet:
if stoplightColor == Red then
"red"
# ...
is converted to:
when stoplightColor is
Red -> "red"
# ...
Does that mean pattern matching is equivalent to if x == y
?
That seems to be the case as long as the matches are a single value. This works:
when 1 + 1 is
2 -> Stdout.line! "math is cool"
_ -> crash "everything you believe in is a lie"
But this doesn't work, with the match as an expression:
when 1 + 1 is
3 - 1 -> Stdout.line! "math is cool"
_ -> crash "everything you believe in is a lie"
I get this error:
MISSING ARROW
I am partway through parsing a `when` expression, but got
stuck here:
6│ when 1 + 1 is
7│ 3 - 1 ->
^
I tried adding parentheses around the expression, and putting the branches on a new indented line, but the error is still there. It seems to be related to the way pattern matching works. Which makes me wonder: is pattern matching really equivalent to if x == y
after all?
It's similar, but not equivalent. We call it matching instead of equivalence checking because we're checking if a value with different possible states matches a pattern that represents a set of those states.
For example,
when user is
{ email, status: Inactive } ->
Stdout.line! "Inactive user found with email $(email)"
This matches on any user that has status == Inactive
, but will allow any user with any email.
The examples you gave at the start are these special cases where instead of matching on structurally equivalent values like { email, status: ... }
, we're instead matching on something that has the same whole value, like 2.
The 3 - 1
thing doesn't work because we don't currently (nor do most languages) have a compiler that's smart enough to know that 3 - 1
is equivalent to 2
.
So in short, when
is close to ==
, but it's smarter in the way that it can capture and use structural content of the matched data, but dumber in that it needs to be given static values, not expressions that evaluate to static values
Gotcha, that makes sense, thanks.
The reason I went down this rabbit hole is that _ if someExpression ->
match syntax makes it easier to fit logic into pattern matching that otherwise wouldn't fit and would have to be changed to a full if-then
expression instead. So that made me wonder about the boundaries between the two syntaxes.
Well, I disagree that a single if
expression linguistically implies you're checking multiple conditions. That's why we have these if-else
chains:
"If X then A else if Y then B else if ..."
when
is meant to imply you're checking multiple conditions. If we found a word that implied both, I'd be more okay with them having the same keyword, but if
is so universal, it'd be pretty hard to argue for getting rid of it
Sorry, I didn't mean to suggest changing when
to if
. I meant that I was thinking about the existing way that if
can be included in a when
match:
when n is
0 -> # ...
1 -> # ...
_ if Num.isEven n -> # ...
_ -> # ...
(And the reason I was thinking about it is that this structure appears in some solutions to the Roc Collatz Conjecture exercise on Exercism.)
Oh, I see. Those are guard statements
Yeah, let me re-read your messages, I may have read too quickly
Okay, having re-read, I think the reason I answered the way I did was because you ended on "that made me wonder about the boundaries between the two syntaxes", and I didn't know how to provide a useful answer to that, so I assumed you were implying the barrier should be dropped.
But I'm not actually sure what the question was, unless you really were just offering food for thought to the group.
Which is totally fine! I'm just tutor-brained right now
No worries, you answered my question when you explained:
The
3 - 1
thing doesn't work because we don't currently (nor do most languages) have a compiler that's smart enough to know that3 - 1
is equivalent to2
.
When I said "that made me wonder…" I was just saying why I asked the question in the first place, because I didn't want to seem like I was arbitrarily complaining about an edge case that doesn't matter in any real scenarios. My mistake for not being clearer that you'd already answered my question! Thanks again.
Great!
Felipe Vogel has marked this topic as resolved.
Last updated: Jul 06 2025 at 12:14 UTC