Re: Fix receive support in erl_eval with a BEAM module

On 05/08/2013 11:56 AM, Björn Gustavsson wrote:
> On Mon, May 6, 2013 at 10:30 PM, Anthony Ramine <[email protected]
> <mailto:[email protected]>> 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
_______________________________________________
erlang-patches mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-patches