Another solution for A is
%{a: "hello", b: "world"}
iex(7)> o = :maps.map(fn (_k,v) -> String.upcase(v) end, i)
%{a: "HELLO", b: "WORLD"}
I don’t know why the Map module doesn’t include a map function. Yes, you can do it with Enum.map but it always returns a list and not a result of the same type as the input. Which I feel is a bit off.
Another solution would be to use for.
Just me hypothesizing:
maps.map/2 generates a list of keywords as an intermediate result.Enum the list is a kind of universal output (iterable) data structure.|>) operator and Enum functions are used in pipelines quite heavily. So once something is a list, it should stay a list throughout the pipeline and not be “rehydrated” until the end of the pipeline (Map.new/1).Map.map/2 there is a speed bump to mindlessly putting Map.map/2 at the beginning (or in the middle) of a pipeline (where map is typically used) - i.e. creating a map that is just going to be converted to a list again.
What I meant was that I think Enum should go type -> type and not type -> list. It feels wrong imao.
Example:
m |> Enum.map(f1) |> Enum.reduce(init,f2)
If m is a Map, it would also be a Map emerging from map/2 which would then have to be converted to a list again before entering reduce/3 - which introduces an unnecessary type->list conversion. It makes more sense to simply leave it as a list and have Collectable reconstitute everything (as desired) at the end of the pipe.
Enum.reduce/3 can already work directly on a map so I don’t see the problem here. I just think it should be enumerable in and not, list out, but enumerable out. It makes it cleaner, imao.
While I don’t have an issue with the implementation compromise for efficiency sake, it’s actually the name map that from my perspective fails the “principle of least astonishment”. When I see a map function I expect it to produce the same shape of data that it consumed - perhaps with a different contained type. That’s because I encountered map in Haskell consciously for the first time and that is how it behaves. So in a way Enum.map/2 sets expectations that it doesn’t deliver on - Enum.map_to_list/2 would be more accurate.
Once I got over my initial “astonishment” I simply reclassified the Enum module as a set of functions that are capable of consuming a range of collections but (mostly) produce output collections as lists (i.e. I took the _to_list suffix as implied).
There are cases, where the input type == output type doesn’t work though:
range = Date.range(~D[1999-01-01], ~D[2000-01-01])
result = Enum.map(range, fn date -> date.day end)
# or
set = MapSet.new([1, 2, 3, 4, 5, 6])
result = Enum.map(set, fn number -> rem(number, 2) end)
Which is why in Haskell the fmap function is tied to the type or more accurately typeclass - so neither Range nor MapSet would be a member of the Functor typeclass.
The original complaint was that there should be a Map.map/2 that produces a Map (while Enum.map_to_list can do whatever it needs to do).
That’s basically what Map.new/2 does. I don’t feel like it gets the attention it deserves, and that probably has to do with the choice/tradeoffs made in the Enum module.