| Age | Commit message (Collapse) | Author |
|---|
|
This complements the `map_get/2` guard BIF introduced in #1784.
Rationale.
`map_get/2` allows accessing map fields in guards, but it might be
problematic in more complex guard expressions, for example:
foo(X) when map_get(a, X) =:= 1 or is_list(X) -> ...
The `is_list/1` part of the guard could never succeed since the
`map_get/2` guard would fail the whole guard expression. In this
situation, this could be solved by using `;` instead of `or` to separate
the guards, but it is not possible in every case.
To solve this situation, this PR proposes a `is_map_key/2` guard that
allows to check if a map has key inside a guard before trying to access
that key. When combined with `is_map/1` this allows to construct a
purely boolean guard expression testing a value of a key in a map.
Implementation.
Given the use case motivating the introduction of this function, the PR
contains compiler optimisations that produce optimial code for the
following guard expression:
foo(X) when is_map(X) and is_map_key(a, X) and map_get(a, X) =:= 1 -> ok;
foo(_) -> error.
Given all three tests share the failure label, the `is_map_key/2` and
`is_map/2` tests are optimised away.
As with `map_get/2` the `is_map_key/2` BIF is allowed in match specs.
|
|
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.
|
|
The ms_transform module, used by ets:fun2ms/1 and dbg:fun2ms,
evaluates constant arithmetic expressions. This is necessary since the
Erlang compiler, which normally evaluates constant expressions, does
not recognize the format generated by ms_transform.
|
|
|
|
Running 'dbg:fun2ms(fun([]) -> return_trace() end' resulted in an error
"dbg:fun2ms requires fun with single variable or list parameter"
But the empty list is actually a list and it is a valid value as a
match-spec head (matching on arity-0 functions).
Although its practical use is questionable this commit eliminates a
small limitation of ms_transform which is not present in the match-spec
grammar.
|
|
|
|
|
|
|
|
|
|
* maint:
Fix miscompilation when module contains multiple named funs
Fix locations of shadowing warnings in ms_transform
|
|
|
|
A shadowed variable in an ms_transform match expression emits a warning
located at the match expression instead of the variable.
|
|
|
|
This adds optional names to fun expressions. A named fun expression
is parsed as a tuple `{named_fun,Loc,Name,Clauses}` in erl_parse.
If a fun expression has a name, it must be present and be the same in
every of its clauses. The function name shadows the environment of the
expression shadowing the environment and it is shadowed by the
environment of the clauses' arguments. An unused function name triggers
a warning unless it is prefixed by _, just as every variable.
Variable _ is allowed as a function name.
It is not an error to put a named function in a record field default
value.
When transforming to Core Erlang, the named fun Fun is changed into
the following expression:
letrec 'Fun'/Arity =
fun (Args) ->
let <Fun> = 'Fun'/Arity
in Case
in 'Fun'/Arity
where Args is the list of arguments of 'Fun'/Arity and Case the
Core Erlang expression corresponding to the clauses of Fun.
This transformation allows us to entirely skip any k_var to k_local
transformation in the fun's clauses bodies.
|
|
|
|
|
|
|
|
Compile below module resulting incorrect warning:
$ cat tmp.erl
-module(tmp).
-export([tmp/1]).
-include_lib("stdlib/include/ms_transform.hrl").
tmp(X) when X > 100 ->
Y=X,
Y;
tmp(X) ->
ets:fun2ms(fun(Y) -> {X, Y} end).
$ erlc tmp.erl
./tmp.erl:8: Warning: variable 'Y' shadowed in ms_transform fun head
The scope for a variable is its function clause. Variables bound in one
function clause should not interfere with other function clauses.
This patch removes incorrect passing of variable bindings from one
function clause to another.
Signed-off-by: Haitao Li <[email protected]>
|
|
|
|
|
|
|
|
Also changed compiler to allow for warnings in parse_transforms.
|
|
|
