Add support to in place add/remove key/values of map in ets:select_replace with match spec

[yushli]

Is your feature request related to a problem? Please describe.

ets:select_replace/2 can use match spec to do in place replacement with List, which is efficient. But it doesn’t support updating map in place.

For example, the change to a list works:
ets:fun2ms(fun({K, L}) when is_list(L) → {K, [marker | L]} end).
Output:
[{{‘$1’,‘$2’},[{is_list,‘$2’}],[{{‘$1’,[marker|‘$2’]}}]}]

But for something similar with map:
ets:fun2ms(fun({K, Map}) when is_map(Map) → {K, Map#{marker => true}} end).
Output:
Error: the language element map (in body) cannot be translated into match_spec {error,transform_error}

Is Erlang/OTP team considering adding support to map as well?

Describe the solution you'd like

ets:select_replace/2 can use match spec to efficiently in place add/remove key/values from a map.

Describe alternatives you've considered

Right now in order to update a map, it needs to read from ets, make the changes, then copy the new map back to ets, which is very inefficient for bigger map. Since Erlang/OTP already support select by key with match spec, it would be consistent to support modification as well.

Additional context

[sverker]

@yushli I did a working proposal in #7326. What do you think?

[yushli]

Looks like it is pretty good. Thanks for this quick working solution!
I just wonder if maps:merge can be added as well. It can be mimic by using multiple maps_put, but not as convenient as have a merge that can update multiple keys at once with simpler syntax.

[sverker]

The problem with BIFs like maps:merge is they can take arbitrary long time to finish if the maps are large enough. In order to not starve other Erlang processes from executing such BIFs might yield execution to be resumed at a later time. The match spec execution engine does not have support for yielding.

[yushli]

Got it. The solution is good enough for simple use cases. Look forward to seeing it merged into mainline.

[christhekeele]

Wanted to add more than a +1 for this feature, so added some thoughts here.

My use case is not with efficiency large maps, but with race conditions in a high-write-concurrency situation where multiple processes tend to want to update just specific values under different specific keys of a map. Being able to read and select_update overwrite just a single map key instead of the whole map would eliminate the major source of race conditions in what I'm working on.