| Age | Commit message (Collapse) | Author |
|---|
|
This can often appear in code after inlining some higher-order
functions.
* mark is_function/2 as pure
* track function types in sys_core_fold
* use those types to eval is_function/1,2 at compile-time when possible
|
|
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 expressions fun M:F/A, when all elements are literals are also
treated as a literal. Since they have consistent representation and
don't depend on the code currently loaded in the VM, this is safe.
This can provide significant performance improvements in code using such
functions extensively - a full function call to erlang:make_fun/3 is
replaced by a single move instruction and no register shuffling or
saving registers to stack is necessary. Additionally, compound data
types that contain such external functions as elements can be treated as
literals too.
The commit also changes the representation of external funs to be a
valid Erlang syntax and adds support for literal external funs to core
Erlang.
|
|
Functions that can are known be pure can be evaluated at
compile-time if the arguments are literals and if the result is
expressible as a literal.
list_to_ref/1 and list_to_port/1 returns terms that cannot be
expressed as literals, so the optimization is not possible.
The argument for port_to_list/1 is never a literal, so there is
no way to evaluate it at compile-time. Therefore, marking those
functions as pure serves no useful purpose.
Note: list_to_pid/1 *is* marked as pure, but only so that we can test
the code in sys_core_fold that rejects pure functions that evaluate to
at term that is not possible to express as a literal. It is sufficient
to have one pure function of that kind.
|
|
erlang:hash/2 was removed in c5d9b970fb5b3a71.
|
|
|
|
|
|
Follow the same pattern as pid_to_list
|
|
|
|
|
|
There is no need to list every obscure safe BIF in erl_bifs:is_safe/3.
The purpose of erl_bifs:is_safe/3 is merely to warn when the
return value of one of the safe BIFs is ignored.
|
|
Add math:floor/1 and math:ceil/1 to avoid unnecessary conversions
in floating point expressions. That is, instead of having to write
float(floor(X)) as part of a floating point expressions, we can
write simply math:floor(X).
|
|
Implement as ceil/1 and floor/1 as new guard BIFs (essentially part of
Erlang language). They are guard BIFs because trunc/1 is a guard
BIF. It would be strange to have trunc/1 as a part of the language, but
not ceil/1 and floor/1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Added: binary_to_integer/1,2, integer_to_binary/1,2
|
|
|
|
Mark math:pi/0 as pure, informing the compiler that the value
can be calculated at compile time.
|
|
concat_binary/1 was deprecated in R13B04, but already in
the R10B-2 release, the documentation recommends using
list_to_binary/1 instead.
|
|
* pan/otp_8217_binary:
Add documentation for binary module
Add more tests and make some go easier on small systems
Correct Boyer More and trapping for longest_common_suffix
Add longer timetrap to testcases and add binary to app file
Add guard BIFs binary_part/2,3
Add binary:{encode,decode}_unsigned({1,2}
Add referenced_byte_size/1
Add binary:list_to_bin/1 and binary:copy/1,2
Add bin_to_list/{1,2,3}
Add binary:longest_common_prefix/longest_common_suffix
Add binary:part to erl_bif_binary.c
Move binary module bif's to erl_bif_binary.c
Count reductions for process even when not trapping
Add random compare testcase
Teach BIF's binary:match/matches interrupting/restarting
Teach binary.c the semantics to take longest instead of shortest match
Initial commit of the binary EEP
OTP-8217 Implement EEP31
The module binary from EEP31 (and EEP9) is implemented.
|
|
Add the gc_bif's to the VM.
Add infrastructure for gc_bif's (guard bifs that can gc) with two and.
three arguments in VM (loader and VM).
Add compiler support for gc_bif with three arguments.
Add compiler (and interpreter) support for new guard BIFs.
Add testcases for new guard BIFs in compiler and emulator.
|
|
|
