[erlang-patches] Fix receive support in erl_eval with a BEAM module

[Anthony Ramine]

Hello Kostis,

It isn't an optimization, it is about getting the operational semantics of erl_eval's receive a little less wrong. Receiving a message shouldn't mess the order of the other messages that didn't get picked up.

It won't break xref, nor Dialyzer nor any other tool if the final .beam file has an abstract code chunk and a stub .erl file is found in the src/ directory.

The stub will contain this:

'receive'(_, _) ->
    erlang:nif_error(stub).

There is nothing more dangerous with this than with BIFs and NIFs.

While I agree that erl_eval not supporting receive correctly is not that important, if there is a way to fix that without breaking stuff, I think it should be done.

Regards,

-- 
Anthony Ramine

Le 8 mai 2013 à 13:15, Kostis Sagonas a écrit :

> 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?