Those results show you are very likely benchmarking without consolidated protocols. Given how maps work, I would expect your implementation to be slower because the only possible way to efficiently traverse a large map and return a map is by doing conversion to a list, traversing and then going from a list to a map. So by definition your solution has to be slower.

This is not related to Ruby at all. I just said this in another thread but the things that are related mostly belong to the syntax.

You explained why we preferred foldable quite well:

Haskell parlance, Foldable is a an interface that is implementable for a larger group of datatypes than Mappable, because things like sets and numerical ranges can be reduced but not mapped

We use foldable because it allows us to support the widest variety of data types, while being efficient and also supporting resources and laziness. Remember that Enum supports resources, so a functor wouldn’t work for most streams either (io, file, stage, etc). You also wouldn’t be able to call a map and return anything that is not a tuple, etc.

EDIT: Introducing reducees « Plataformatec Blog - this article explains how the protocol works with the widest variety of data types as possible. And that was the goal, to have a single protocol instead of multiple ones. There is still space for a functor/traverse but given that even map operations require you to first convert to a list and then back, it does not add much beyond to what we have today.

As for:

Enum does not (contrary to what intuition might suggest) implement the Functor (fun_land source code) pattern. Thus Enum.map is not a 'true map` because indeed it (and all functions that are based on it) always returns a list rather than ‘a container with transformed contents but with the same containing structure’.

Instead of on map, Enum is built on the concept of reduce Reducable(fun_land source code) or, in Haskell parlance, Foldable is a an interface that is implementable for a larger group of datatypes than Mappable, because things like sets and numerical ranges can be reduced but not mapped (since then it would be possible to end up with two values with the same value, which goes against the invariant of a set).

So why do you care about Functor-style ‘true’ map? Because Enum.map and similar functions throw away the structure of the container. If you have a (rose) tree, good luck on iterating it using Enum.map and in the end attempting to regain the same tree structure as before.

I have the feeling (please correct me if I’m wrong, @josevalim) that the current approach of Enum.map being built on top of reduce was to be able to use iteration functions with these other data types, and that this choice might’ve been influenced by Ruby, which takes the same approach.