Why doesn't erl_eval compile code?

[Tony Arcieri]

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