Map.update(data, :c, [10], &([10|&1]))
I think this is one of those cases where the choice is arbitrary because either one will sometimes be the less convenient choice.
sribe
rvirding
Creator of Erlang
Well Map.update is defined as update(map, key, initial, fun) and the comment says:
" If key is present in map with value value , fun is invoked with argument value and its result is used as the new value of key . If key is not present in map , initial is inserted as the value of key . The initial value will not be passed through the update function."
One reason for this is that there is no predefined default value for keys so assuming it is [] (or anything else for that matter) would be really weird as it pre-supposes that values have a specific type.
0
sribe
It would be totally not in the spirit of Erlang & Elixir to have a default value associated with a map. But it would not be unreasonable, when key does not have an entry, to pass initial into fun. I prefer it the way it is, explicitly specifying initial, but the other way would not have been wrong.
1
7stud
Who the heck proposed that the default value for a key should be an empty list? Please quote somebody.
0
7stud
I don’t believe that at all. Perl is one of the, if not the, pre-eminent text processing languages. It has a feature called autovivification, where if you treat a value returned by a key as a list, then Perl creates the list for you and assigns it to the key, or if you treat the value returned by a key as a hash, then Perl creates a hash for you and assigns it to the key. I’ve never heard anyone in the Perl world say, “Boy, this autovivification really sucks.” Ruby recognized that autovivification was a great feature and incorporated it into Hash.new. And, as far as I can tell, Elixir is the rubification of erlang, so it makes sense to me that the great features of Ruby would be features in Elixir as well.
0
sribe
You did not propose that exactly, but youd did mention the Ruby ability to set a default value on a per-map basis when the map is created.
(Later you called the fact that update does not pass the default to the fun a “terrible oversight” which I think is just wrong. As I said in an earlier post, it’s one of those choices where neither will be the most convenient all the time. And I prefer the way Elixir does it now because I think it’s more explicit what happens, one value for what happens if the key is not set, one function for what happens if the key is set, with no implicit connection between the two.)
0
sribe
Elixir is not Perl. The phrase “if you treat a value returned by a key as a list” makes no sense in the Elixir context–you’re basically saying “if you expect of type XXX and you get nil, then automagically create an XXX and substitute it”, and that is exactly the kind of implicit magic that Elixir tries to avoid, by design.
3
7stud
Elixir streams aren’t implicit magic? What about the Keylist syntax [a: 1, b: 2]? Or, the implicit magic involved in the syntax &(&1*&1)? From what I’ve seen, Elixir incorporates black magic frequently.
In any case, thanks to all who commented. I was searching for a feature that doesn’t exist, and I will have to make do.
0
sribe
Don’t confuse syntactic sugar and implicit magic–the examples you post are all completely explicit.
2
OvermindDL1
Not remotely? Stream’s are just a function composition pattern that is common in most languages (built in to the very fabric of some like Haskell) but are entirely non-opaque.
Syntax sugar that turns a: 1 into {:a, 1} (though the fact you can’t freely intermix those constantly drives me crazy).
Syntax sugar that turns that in to fn a -> a*a end, a useful and common shortening for something very commonly used.
Elixir has plenty of inconsistent bits in it’s syntax, and other than the ordering of a: 1 things none of the above is that. 
It’s trivial to make your own yeah, though I too always preferred if the initial in update/4 was actually the default passed in so I can properly dynamically create either the start or the next in the function without incurring a cost on initial potentially unused construction every call.
0