| Age | Commit message (Collapse) | Author |
|---|
|
The expression in a bit string comprehension is limited to a
literal bit string expression. That is, the following code
is legal:
<< <<X>> || X <- List >>
but not this code:
<< foo(X) || X <- List >>
The limitation is annoying. For one thing, tools that transform
the abstract format must be careful not to produce code such as:
<< begin
%% Some instrumentation code.
<<X>>
end || X <- List >>
One reason for the limitation could be that we'll get
reduce/reduce conflicts if we try to allow an arbitrary
expression in a bit string comprehension:
binary_comprehension -> '<<' expr '||' lc_exprs '>>' :
{bc,?anno('$1'),'$2','$4'}.
Unfortunately, there does not seem to be an easy way to work
around that problem. The best we can do is to allow 'expr_max'
expressions (as in the binary syntax):
binary_comprehension -> '<<' expr_max '||' lc_exprs '>>' :
{bc,?anno('$1'),'$2','$4'}.
That will work, but functions calls must be enclosed in
parentheses:
<< (foo(X)) || X <- List >>
|
|
|
|
|
|
Removing events from the internal queues is not necessary with
the choosen semantics of the event queue vs. hibernate.
In an early implementation it was possible by combining
hibernate with e.g. postpone to get an event in the queue
that you would not see before processing the postponed event,
and therefore should you decide to cancel a timer it was
essential to be able to remove that unseen event from the queue.
With the choosen semantics you will have to postpone or generate
an event for it to be in the event queue, and if you e.g. postpone
a timeout event and then cancel the timer it is your mistake.
You have seen the event and should know better than to try to
cancel the timer.
So, the actions: remove_event, cancel_timer, demonitor and unlink
are now removed.
There have also been some cleanup of the timer handling code.
|
|
|
|
|
|
|
|
|
|
|
|
Type check atom state as early as possible
|
|
|
|
|
|
|
|
* siri/remove-overload/OTP-13184:
Remove module 'overload' from SASL
|
|
Correct typo reported by Luïc Hoguin.
|
|
|
|
|
|
* benwilson512/better-maps-with:
Improved maps:with/2 and maps:without/2 algorithm
OTP-13376
|
|
|
|
|
|
StateName/4 -> StateName/3
handle_event/5 -> handle_event/4
|
|
Define options as actions that set options,
rework the documentation about this.
|
|
|
|
Cleanup some error handling
|
|
|
|
|
|
|
|
|
|
|
|
The reason is that the module is not used, and that we se no obvious
use case for it.
|
|
|
|
|
|
|
|
|
|
Forms with record field types created before OTP 19.0 are replaced by
well-formed record forms holding the type information.
Tools reading the 'abstract_code' chunk can rely on the returned forms
being well-formed, that is, there are no badly formed 'type' attribute
forms.
|
|
|
|
|
|
* bjorn/stdlib/function-macro/OTP-13059:
Implement ?FUNCTION_NAME and ?FUNCTION_ARITY macros
epp: Refactor expand_macros()
|
|
* bjorn/remove-test_server/OTP-12705:
Remove test_server as a standalone application
Erlang mode for Emacs: Include ct.hrl instead test_server.hrl
Remove out-commented references to the test_server applications
Makefiles: Remove test_server from include path and code path
Eliminate use of test_server.hrl and test_server_line.hrl
|
|
|
|
|
|
|
|
|
|
For a long time, users have asked for one or more macros that would
return the name and arity of the current function.
We could define a single ?FUNCTION macro that would return
a {Name,Arity} tuple. However, to access just the name or
just the arity for the function, element/2 must be used.
That would limit its usefulness, because element/2 is not
allowed in all contexts.
Therefore, it seems that we will need two macros.
?FUNCTION_NAME that expands to the name of the current function
and ?FUNCTION_ARITY that expands to arity of the current
function.
Converting the function name to a string can be done like this:
f() ->
atom_to_list(?FUNCTION_NAME) ++ "/" ++
integer_to_list(?FUNCTION_ARITY).
f/0 will return "f/0". The BEAM compiler will evaluate the
entire expression at compile-time, so there will not be
any run-time penalty for the function calls.
The implementation is non-trivial because the preprocessor is
run before the parser.
One way to implement the macros would be to replace them with some
placeholder and then let the parser or possibly a later pass replace
the placeholder with correct value. That could potentially slow
down the compiler and cause incompatibilities for parse transforms.
Another way is to let the preprocessor do the whole job. That means
that the preprocessor will have to scan the function head to find
out the name and arity. The scanning of the function head can be
delayed until the first occurrence of a ?FUNCTION_NAME or
?FUNCTION_ARITY.
I have chosen the second way because it seems less likely to cause
weird compatibility problems.
|
|
As a preparation for implementing a ?FUNCTION macro, pass the
entire state record to expand_macros/2 and its helpers. That will
allow us to have more information available when expanding
?FUNCTION.
|
|
|
|
|
|
|
|
|
|
|
