[erlang-questions] Why doesn't erl_eval compile code?

[Robert Virding]

Seeing no one has replied I will give some comments:

- What problem are you trying to solve? I admit that it would be cool to do
it, but why?
- While the fun code is not very elegant :-), it does work as it should.
What does not work as it should is interpreting receive.
- If you remove the module when you are done, which you must explicitly do,
then there could be some problem with funs if you have passed them on and
they still are in use as they will not work after their module has been
removed.
- The interpreter was never intended to run larger programs so in one
respect it wold be a waste of time.
- If you implemented this then PDQ you would get requests to be able to
define functions and modules in the shell. :-)

But it would be cool code,

Robert

2009/6/24 Tony Arcieri <tony@REDACTED>

> In its present implementation erl_eval accepts an Erlang parse tree and it
> walks the nodes of the parse tree, evaluating them node by node.  This is
> somewhat inelegant in many cases, such as when you run into constructs like
> funs:
>
> http://gist.github.com/79022
>
> Why not transform the parse tree into something that provides erl_eval's
> return value (i.e. real return value + final bindings), compile that to a
> temporary module, load that into the code server, and execute it, removing
> the module when it's done.  Wouldn't that solution provide more consistent
> semantics while also being faster at things like tail calls and other
> computationally complex problems?
>
> I'll go ahead and concede there's a great deal of complexity to both
> solutions, and the compiled solution presents some concurrency problems, as
> I understand.  Please expound on that issue either way.
>
> As a bit of background, I'm working on moving the eval strategy of my
> language Reia (which runs on the Erlang VM) off of erl_eval completely,
> having it always compile to BEAM/HiPE bytecode, to make the semantics more
> consistent and also improve performance.  I'm curious why Erlang doesn't
> take this approach.
>
> --
> Tony Arcieri
>