aboutsummaryrefslogtreecommitdiffstats
path: root/erts/emulator/beam/erl_db_util.c
diff options
context:
space:
mode:
authorMichał Muskała <[email protected]>2018-02-03 15:41:11 +0100
committerMichał Muskała <[email protected]>2018-04-24 11:57:29 +0200
commitad72c0d37ffb214cac874f51ac29fe2cdb47a2a4 (patch)
treefcc905efbf7a6e10aa4a0b8358910dc4242c47ff /erts/emulator/beam/erl_db_util.c
parenta5dc5af3fe3b1e25f0596d71d3ac36291b0099dc (diff)
downloadotp-ad72c0d37ffb214cac874f51ac29fe2cdb47a2a4.tar.gz
otp-ad72c0d37ffb214cac874f51ac29fe2cdb47a2a4.tar.bz2
otp-ad72c0d37ffb214cac874f51ac29fe2cdb47a2a4.zip
Introduce map_get guard-safe function
Rationale Today all compound data types except for maps can be deconstructed in guards. For tuples we have `element/2` and for lists `hd/1` and `tl/1`. Maps are completely opaque to guards. This means matching on maps can't be abstracted into macros, which is often done with repetitive guards. It also means that maps have to be always selected whole from ETS tables, even when only one field would be enough, which creates a potential efficiency issue. This PR introduces an `erlang:map_get/2` guard-safe function that allows extracting a map field in guard. An alternative to this function would be to introduce the syntax for extracting a value from a map that was planned in the original EEP: `Map#{Key}`. Even outside of guards, since this function is a guard-BIF it is more efficient than using `maps:get/2` (since it does not need to set up the stack), and more convenient from pattern matching on the map (compare: `#{key := Value} = Map, Value` to `map_get(key, Map)`). Performance considerations A common concern against adding this function is the notion that "guards have to be fast" and ideally execute in constant time. While there are some counterexamples (`length/1`), what is more important is the fact that adding those functions does not change in any way the time complexity of pattern matching - it's already possible to match on map fields today directly in patterns - adding this ability to guards will niether slow down or speed up the execution, it will only make certain programs more convenient to write. This first version is very naive and does not perform any optimizations.
Diffstat (limited to 'erts/emulator/beam/erl_db_util.c')
-rw-r--r--erts/emulator/beam/erl_db_util.c8
1 files changed, 6 insertions, 2 deletions
diff --git a/erts/emulator/beam/erl_db_util.c b/erts/emulator/beam/erl_db_util.c
index 3836f28aa4..6354abfd1f 100644
--- a/erts/emulator/beam/erl_db_util.c
+++ b/erts/emulator/beam/erl_db_util.c
@@ -638,6 +638,12 @@ static DMCGuardBif guard_tab[] =
DBIF_ALL
},
{
+ am_map_get,
+ &map_get_2,
+ 2,
+ DBIF_ALL
+ },
+ {
am_bit_size,
&bit_size_1,
1,
@@ -5737,5 +5743,3 @@ void db_match_dis(Binary *bp)
}
#endif /* DMC_DEBUG */
-
-