Is it possible to partially pattern-match Lists as we do with Maps?

Questions / Help
, ,
#1

Hello everybody,

As it’s possible to partially pattern match with maps like so:

iex> %{b: 2} = %{a: 1, b: 2, c: 3}
%{a: 1, b: 2, c: 3}

Is it possible to do the same with Lists, e.g. like that:

iex> [2] = [1, 2, 3]
# MatchError

I guess that the inherent nature of linked lists (which make it easy to pattern-match heads/tails) might complicate things. Also I got the fact that in this case it might not make sense to pattern-match for variable binding . But it might be useful to pattern-match in this case for conditions/tests.

One can simply use Enum.member? but I don’t see an easy way to avoid conditions like we do when using pattern-matching in general or in functions argument.

Thank you very much for any details…

#2

Hi @Sanjibukai you can match on the head and tail of a list, but there is no way to do a match which asks “Is this value anywhere in the list”.

[head | tail] = [1,2,3]
head #=> 1
tail #=> [2,3]
2 Likes
#3

Hello,

Yes I know about head/tail pattern-matching for Lists but I was curious to know if more elaborated options exists… Maybe with more advanced Elixir Data Structure besides Maps?

Just noticed the tag besides your username… I bought your book :wink:. A long time ago tbh… But it’s on the queue… I’m currently learning Elixir/Phoenix basics from other PragProg books I have…

#4

As @benwilson512 said, you cannot pattern match in the middle of a list. If you are looking for a convenient and readable way to check for inclusion, you can do this though:

2 in [1, 2, 3]

You can also use it in guards:

case 2 do
  x when x in [1, 2, 3] -> :yes
  _ -> :no
end
2 Likes
#5

I forgot that notation… Indeed it’s great!

Then I guess that it might work in a pattern-matching when matching with true, like so:

def some_func(true) do
  # value present
end

def some_func(false) do
#  value absent
end

some_func(val in list)
#6

Or even easier, as you can use it in guards:

def some_func(x) when x in [1, 2, 3] do
  :present
end

def some_func(_) do
  :not_present
end
5 Likes
#7

Is it possible to use that bit (conditional of the case) in a function argument as pattern-matching purpose?

EDIT: Thanks I saw your answer above!

#8

Yes, like I posted before (we’re replying to each other fast so some posts are probably noticed only after pressing “reply” :slight_smile: )

EDIT: indeed it happened again :smile:

1 Like
#9

Yeah I noticed it, and edited!
in fact you just gave me what I was looking for (namely guard clause) but I might stated the problem wider to learn a little more :wink:

1 Like
#10

It’s interesting to notice how the guard is implemented. It is documented here and basically translates this:

when x in [1, 2, 3]

Into this:

when x === 1 or x === 2 or x === 3

The guard also works for ranges, with a different implementation, as the documentation shows.

2 Likes
#11

Yeah, this different implemantation introduces slightly “bugs” if not understood correctly:

def f(x) when x in [1,2,3], do: "123"
def f(x) when x in 4..6, do: "456"
def f(_), do: "nope"

IO.puts f(2) #=> 123
IO.puts f(2.0) #=> nope
IO.puts f(2.5) #=> nope
IO.puts f(5) #=> 456
IO.puts f(5.0) #=> 456
IO.puts f(5.5) #=> 456
4 Likes
#12

According to the doc linked by @lucaong it should still work in these examples since:

when x in 1..3
translates to:
when is_integer(x) and x >= 1 and x <= 3
Note that only integers can be considered inside a range by in .

Also, I just tried and indeed I got:

IO.puts f(5) #=> 456
IO.puts f(5.0) #=> nope
IO.puts f(5.5) #=> nope

Edit: I think that this bit is_integer(x) and might be an addition brought by an update later on…
Also it’s still interesting to know and behaves carefully with edge cases.

#13

Important thing to notice in order to understand the behavior of in with ranges, is that a range is an Enumerable of integers. Therefore, (0..10) includes 5 but not 5.5, nor 5.0 (see the is_integer(x) in the guard expansion).

That is consistent with how Enum.member? works on ranges:

Enum.member?(0..10, 5) #=> true
Enum.member?(0..10, 5.5) #=> false
Enum.member?(0..10, 5.0) #=> false

In other words, it could be considered surprising, but it is not a bug, it is intended behavior.

2 Likes
#14

Oh, nice, Then either things have changed with newer versions of elixir, or something else bit me years ago…

2 Likes
#15

In fact I just checked and indeed…
It happened 3 years ago…

1 Like
#16

Thats just documentation… I went back in that file another 2 years, and the is_integer/1 check for left has been there in every commit…

1 Like
#17

Indeed… My bad…
It was 5 years ago…

EDIT: It’s still not that… I went to fast with the commit messages…

#18

This is quite surprising but makes me feel really good about myself because I always assert on the type first and then on the range of acceptable values. :024:

EDIT: Oops, I didn’t read all comments before commenting but the remark still stands.