Put/update deep inside nested maps (and auto-create intermediate keys)

To my knowledge, put_in, Map.update etc. all have the one limitation of not automatically creating intermediate keys when needed (for example, put_in(%{a: %{}}, [:a, :b, :c], 42) will fail). But – despite all the risks – this would be useful to have: for instance, I often use reduce to create a nested, aggregate representation of a list of complex objects (say, counting occurrences by categories and sub-categories), which is a one-liner when you don’t have to worry about intermediate keys (think mkdir -p).

The implementation is simple enough (see deep_update example below, which I’m already using all over my projects). I have a nagging feeling this must already be part of Elixir’s standard library and I just don’t know about it? If not, is there a particular reason it isn’t?

  %spec deep_update(map(), [any()], any(), any() -> any()) :: map()
  def deep_update(map, [leaf_key], default, update_func) do
    updated_leaf = if is_map(map) and Map.has_key?(map, leaf_key) do
      update_func.(map[leaf_key])
    else
      default
    end
    Map.put(map, leaf_key, updated_leaf)
  end
  def deep_update(map, [key | key_tail], default, update_func) do
    if is_map(map) and Map.has_key?(map, key) do
      new_branch = deep_update(map[key], key_tail, default, update_func)
      Map.put(map, key, new_branch)
    else
      new_branch = deep_update(%{}, key_tail, default, update_func)
      Map.put(map, key, new_branch)
    end
  end
3 Likes

Not entirely sure if this addresses what you are trying to accomplish but have you had a look at Kernel.put_in/3, Kernel.get_and_update_in/3 and the like - and Access behavior?

1 Like

put_in and get_and_update_in have the same limitation I described, and I don’t know of any Access functions that do what I’m looking for (do correct me if they exist).

So if I understand you correctly you want

put_in(%{a: %{}}, [:a, :b, :c], 42)

to result in

%{a: %{b: %{c: 42)} } }

One problem I see is that you are assuming that :b should refer to a Map value i.e. that the nested structure is a homogenous Map. The Access data[key] syntax is right out of the box also supported by Keyword lists - and any other structure that cares to implement the Access behaviour so there is some ambiguity right there - just because there is a key doesn’t automatically mean it should be a Map.

Yeah, that would explain why Access behaviour doesn’t cover this. I obviously only use this for plain maps-of-maps. Still, it could be part of the Map module?

Nobody is stopping you from creating helpers that you use because that is a simplifying assumption that you want to make in your own code and your own structures.

But in general terms looking at just [:a, :b, :c] the types of the values referenced by :a and b: can’t be known unless they already exist - with :c the type is known because you are giving it the value. Map simply manages the keys and the values - it doesn’t want to make any assumptions about the type of values it manages so that it can be generic.

Fair point, thanks @peerreynders

You can achieve this today using Access.key/2:

put_in(%{a: %{}}, Enum.map([:a, :b, :c], &Access.key(&1, %{})), 42)

If you use it often, you could wrap it in a function to do this automatically for you.

22 Likes

Ahhh, very cool. I’d seen Access.key before but never made the connection that I could use it like that. Thanks Michał! :+1:

This is really great, does anyone one know why it’s in Kernel and not Map, though?

put_in can manipulate anything that Access supports, not just maps. For instance:

iex(1)> a = {1, 2, :x}
{1, 2, :x}
iex(2)> put_in a, [Access.elem(2)], :foo
{1, 2, :foo}
1 Like