aboutsummaryrefslogtreecommitdiffstats
path: root/lib/stdlib/src/ms_transform.erl
AgeCommit message (Collapse)Author
2018-08-31Fix type spec of ms_transform:parse_trans/2Péter Gömöri
It can also return errors and warnings.
2018-06-18Update copyright yearHenrik Nord
2018-04-29Introduce is_map_key/2 guard BIFMichał Muskała
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.
2018-04-24Introduce map_get guard-safe functionMichał Muskała
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.
2017-06-12stdlib: Evaluate expressions in fun2ms bodiesHans Bolinder
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.
2017-06-09stdlib: Handle Unicode atoms in ms_transformHans Bolinder
2016-10-13dbg:fun2ms: allow empty list as headPéter Gömöri
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.
2016-06-09stdlib: Correct types and specsHans Bolinder
2016-02-17stdlib: Update ms_transform to handle typed record fieldsHans Bolinder
2015-06-18Change license text to APLv2Bruce Yinhe
2015-04-30stdlib: Use module erl_annoHans Bolinder
2014-11-17Merge branch 'maint'Björn Gustavsson
* maint: Fix miscompilation when module contains multiple named funs Fix locations of shadowing warnings in ms_transform
2014-08-20Support maps in ms_transformAnthony Ramine
2014-06-15Fix locations of shadowing warnings in ms_transformAnthony Ramine
A shadowed variable in an ms_transform match expression emits a warning located at the match expression instead of the variable.
2014-01-28erts,stdlib: Teach matchspec compiler map guardsBjörn-Egil Dahlberg
2013-12-12EEP 37: Funs with namesAnthony Ramine
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.
2013-01-25Update copyright yearsBjörn-Egil Dahlberg
2013-01-25Make adjustments for UnicodeHans Bolinder
2012-01-26Remove support for is_constant/1 in ms_transformBjörn Gustavsson
2011-09-08ms_transform: Fix incorrect `variable shadowed' warningsHaitao Li
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]>
2011-05-12Types and specifications have been modified and addedHans Bolinder
2011-03-11Update copyright yearsBjörn-Egil Dahlberg
2010-06-23Add testcases for ms_transform warning and fix scopingPatrik Nyblom
2010-06-23Add warnings for shadowed variables in ms_transform funsPatrik Nyblom
Also changed compiler to allow for warnings in parse_transforms.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP