[erlang-patches] Fix receive support in erl_eval with a BEAM module
Kostis Sagonas
kostis@REDACTED
Wed May 8 13:15:31 CEST 2013
On 05/08/2013 11:56 AM, Björn Gustavsson wrote:
> On Mon, May 6, 2013 at 10:30 PM, Anthony Ramine <n.oxyde@REDACTED
> <mailto:n.oxyde@REDACTED>> wrote:
>
> Hello,
>
> 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.
>
> git fetch https://github.com/nox/otp.git erl_eval-receive
>
> https://github.com/nox/otp/compare/erlang:maint...erl_eval-receive
> https://github.com/nox/otp/compare/erlang:maint...erl_eval-receive.patch
>
> Regards,
>
>
> We found it strange to put BEAM assembly language files
> in the STDLIB application (in theory, STDLIB should
> be possible to use in other Erlang implementations).
>
> I think that a better place would be to make it a pre-loaded
> module in the erts application. Also, I suggest that instead
> of calling a hard-coded function, the function can call a
> fun.
I think this patch possibly opens up a can of worms. Once upon a time,
the OTP libraries only contained Erlang code and calls to a set of BIFs
implemented in C. Now we also get .S modules in the distribution and
Erlang code now can call these "fake" modules. This is (and will
continue to be) a problem for all tools like xref, dialyzer, testing
tools, etc. that want to analyze Erlang applications or manipulate code
bases.
What's bad is that the BEAM code contained in these files has no
correspondence to any Erlang code (please correct me if I am wrong in
this) and the semantics of BEAM instructions are nowhere formally described.
Am I the only one that sees a problem here? Is this "optimization" of
erl_eval really worthwhile? Is it needed?
Kostis
More information about the erlang-patches
mailing list