Why do we need to use Enum.into(%{})?

Questions / Help
, ,
1

I know this is a really minor peeve, but why is this the case?:

iex(cs@localhost)54> %{key1: :i_am_a_map_whooot} |> Enum.map(&(&1))
[key1: :i_am_a_maaa___list__what_the?]

Yes I know that all I need to do is |> Enum.into(%{}) but why? Why shouldn’t the ouput type be the same as the input type?

I’m sure this has been asked 1000 times before.

2

You don’t have to. You can call reduce over new map like this:

iex> Enum.reduce(%{a: 1, b: 2, c: 3}, %{}, fn {key, value}, acc ->
  Map.put(acc, key, value * 2)
end)
%{a: 2, b: 4, c: 6}

Note: The order of map elements is not guaranteed to be sorted.

3

But, I don’t know, seems like extra work. I’m so used to it that it doesn’t bother me that much, I just thought that it was an odd implementation detail.

Maybe we need an Enum.fmap/2 like Haskell?

4

Using Enum.map or Enum.reduce and working with two-tuples and then just doing Map.new does not justify the need for a function that does the same IMO. Just do your stuff and slap a Map.new at the end.

5

One thing is that the result of your map operation is in a predictable order. I don’t have a real world example of where this would particularly useful, but in a pipeline it could be. Having each result getting converted back to a map would be pretty chaotic.

1 Like
6

Oh, right I forgot about it. Unfortunately we do not have a way to map the Map without converting it first to a list, see:

So at the very end we do exactly the same. :slightly_frowning_face:

7

Yep, I also checked the Elixir source a while ago. IMO doing Map.new only once is more performant than doing N times Map.put so I am always doing that.

1 Like
8

As mentioned before, Enum.map on a map returns a list because this would fit better to pipes without the need to convert to a list and back behind the scenes in every step.

There used to be the Map.map/2 function in Elixir, which is now deprecated. But you get the same result with Map.new/2.

iex(1)> map = %{a: 1, b: 2, c: 3}
%{c: 3, a: 1, b: 2}
iex(2)> Map.map(map, fn {key, value} -> {key, value * value} end)
warning: Map.map/2 is deprecated. Use Map.new/2 instead (invoke Map.from_struct/1 before if you have a struct)
└─ iex:2

%{c: {:c, 9}, a: {:a, 1}, b: {:b, 4}}
iex(3)> Map.new(map, fn {key, value} -> {key, value * value} end)
%{c: 9, a: 1, b: 4}
2 Likes
9

Except when the input is a map, there is no guarantee about order in the first place. So this argument doesn’t seem to hold.

For the argument that conversion would take place between steps in a pipe; why would it? Elixir can detect it is in a pipeline and not convert in between as an optimization.

Once you know the ‘conversion’ it does not matter that much anymore. But I see how returning the same type as the input makes sense from a developer experience.

10

The output type of Enum.map (and most Enum functions) cannot be the same as the input type because Enum works on a variety of data types through the Enumerable protocol. A simple example is:

iex> Enum.map(1..3, & &1 ** 2)
[1, 4, 9]

We couldn’t possibly keep the shape of the input, %Range{}, because the end result would be nonsensical. Some other things that implement Enumerable protocol are file streams and even infinite streams.

As was mentioned before there used to be a Map.map/2 but it got deprecated because a similar function existed all along, Map.new/2:

iex> Map.new(1..3, fn i -> {i, i ** 2} end)
%{1 => 1, 2 => 4, 3 => 9}

so yeah, long story short, in your particular case instead of Enum.map/2 use Map.new/2.

13 Likes
11

Seems an implementation detail in the case of Range. From an outside perspective the range simply expands to a list so a list in return makes sense. As far as I can see the sole reason for having a ‘Range’ struct during processing is optimization, and explicit use of the struct is deprecated.

—-snip this part: Too early in the morning—-
—- and the start was incorrect too, see below —-

12

I’m not sure how to respond to that. Fwiw this quote from docs might be helpful:

https://hexdocs.pm/elixir/1.16.2/Collectable.html#module-why-collectable

The Enumerable protocol is useful to take values out of a collection. In order to support a wide range of values, the functions provided by the Enumerable protocol do not keep shape. For example, passing a map to Enum.map/2 always returns a list.

This design is intentional. Enumerable was designed to support infinite collections, resources and other structures with fixed shape. For example, it doesn’t make sense to insert values into a Range, as it has a fixed shape where only the range limits and step are stored.

The Collectable module was designed to fill the gap left by the Enumerable protocol.

1 Like
13

Just to correct myself: yes, in an Enum.map the Range is a list from an outside perspective. However when seeing the same syntax in
‘slice’ this is different and you do not see it as a ‘shortened version of a list’

So indeed the only answer is compatibility and the output making sense at all times.

Also this is something you only trip over until your head starts seeing it less as ‘map’ and more as ‘map during enumeration’ where the latter more clearly point to a list in return.

14

I did mean when the input was a map and I was talking about what comes out is ordered from there onward. It could be different on subsequent runs, so ya, wasn’t really sure if that is useful. Although:

True! Though that would certainly be surprising behaviour.

15

Still, the structure preserving Enum.map would be not possible in case like:

map = %{2 => 1, 3 => 7}

Enum.map(map, fn {a, b} -> a + b end)
3 Likes