| Age | Commit message (Collapse) | Author |
|---|
|
files as delimiters.
While working on a tool that processes Erlang code and testing it against this repo,
I found out about those little sneaky 0xff. I thought it may be of help to other
people build such tools to remove non-conforming-to-standard characters.
|
|
Using the low-level BEAM instructions, we can loop over each message in
the process queue and removes the first message that matches, without
receiving them all to later send them back to itself.
The function prim_eval:'receive'/2 is equivalent to the
following pseudo-code:
'receive'(F, T) ->
RESET MESSAGE QUEUE POINTER,
LOOP:
case PEEK CURRENT MESSAGE WITH TIMEOUT T of
{ok,Msg} ->
case F(Msg) of
nomatch ->
DECREMENT TIMEOUT T,
ADVANCE MESSAGE QUEUE POINTER,
GOTO LOOP;
Result ->
RESET MESSAGE QUEUE POINTER,
Result
end;
timeout ->
RESET MESSAGE QUEUE POINTER,
timeout
end.
To not break Dialyzer and other tools, we use a stub Erlang module which
abstract code is forcefully inserted into prim_inet.erl afterwards
compilation.
|
|
Tuples funs were removed in de7e01c958ff7c9e6da4034a53567a30a4ae5792,
but it was still possible to evaluate tuple funs in the shell.
|
|
|
|
|
|
|
|
|
|
Currently, the external fun syntax "fun M:F/A" only supports
literals. That is, "fun lists:reverse/1" is allowed but not
"fun M:F/A".
In many real-life situations, some or all of M, F, A are
not known until run-time, and one is forced to either use
the undocumented erlang:make_fun/3 BIF or to use a
"tuple fun" (which is deprecated).
EEP-23 suggests that the parser (erl_parse) should immediately
transform "fun M:F/A" to "erlang:make_fun(M, F, A)". We have
not followed that approach in this implementation, because we
want the abstract code to mirror the source code as closely
as possible, and we also consider erlang:make_fun/3 to
be an implementation detail that we might want to remove in
the future.
Instead, we will change the abstract format for "fun M:F/A" (in a way
that is not backwards compatible), and while we are at it, we will
move the translation from "fun M:F/A" to "erlang:make_fun(M, F, A)"
from sys_pre_expand down to the v3_core pass. We will also update
the debugger and xref to use the new format.
We did consider making the abstract format backward compatible if
no variables were used in the fun, but decided against it. Keeping
it backward compatible would mean that there would be different
abstract formats for the no-variable and variable case, and tools
would have to handle both formats, probably forever.
Reference: http://www.erlang.org/eeps/eep-0023.html
|
|
'eval_bits' is a common utility module used for evaluting binary
construction and matching. The functions that do matching
(match_bits/{6,7} and bin_gen/6) are supposed to treat the bindings as
an abstract data type, but they assume that the bindings have the same
representation as in the erl_eval module. That may cause binary
matching to fail in the debugger, because the debugger represents the
bindings as an unordered list of two-tuples, while the erl_eval
modules uses an ordered list of two-tuple (an ordset).
One way to fix the problem would be to let the debugger to use ordered
lists to represent the bindings. Unfortunately, that would also change
how the bindings are presented in the user interface. Currently, the
variable have most been recently assigned is shown first, which is
convenient.
Fix the matching problem by mending the leaky abstraction in
eval_bits. The matching functions needs to be passed two additional
operations: one for looking up a variable in the bindings and one for
adding a binding. Those operations could be passed as two more funs
(in addition to the evaluation and match fun already passed), but the
functions already have too many arguments. Therefore, change the
meaning of the match fun, so that the first argument is the operation
to perform ('match', 'binding', or 'add_binding') and second argument
is a tuple with arguments for the operation.
|
|
A specification that could cause problems for Dialyzer has been fixed.
An opaque type in erl_eval has been turned in to a ordinary type. This
is a temporary fix.
|
|
|
|
|
