cerl module; Core Erlang "forms"

[mccratch@REDACTED]

thanks for the replies.

Richard Carlsson wrote:
[...]
> What I described above is only true from the Core Erlang level down;
> the later stages treat integer-named variables in the same way, and do
> not convert them (as far as I know - does Björn have a comment?), until
> all variables are replaced with Beam abstract machine registers. Stages
> before Core Erlang probably do not like integers.
[...]

hmm this seems to be good, but something come up my mind that I seem to
overlooked. Whats with locally defined (or globally defined) functions?
If I interpret the error messages/stack backtraces correctly they are
given names. Are those names atoms and are those atoms put into the
executable? If this is the case then I can simply restrict the number of
possible local functions. If I understand it correctly the local
functions aren't given random names, but the names are directly derived
from the function name they are declared in with some postfix or so. So
if I use only a specific predefined entry function (I am just want to be
able to compile some expressions and then run them), then the atom table
shouldn't overflow.

On 2005-04-14 at 10:54:30 (-0400), Vance Shipley wrote:
> When Joe made the comment that the lack of atom GC would negate the
> possibility of a compilation server I thought "too bad that sounded
> like a good idea!".  Recently I was thinking about this and realized
> that it is a simple problem to solve.  Using the slave module you can
> start up new nodes.  The pool module manages a pool of slave nodes
> and predicts the best one to use based on load.  So you would have a
> master node accepting compilation requests and farming the jobs out 
> to slave nodes.  If the pool module restarts slave nodes which exit 
> you could just have the job be compile and then exit.  

I had this idea, too, but thought it would be much easier if I don't
have to copy the modules and uncompiled code/information used for
generating the code between two nodes. (well just something that came to
my mind now: does the runtime uses an optimized routine for copying
terms between two nodes if they are running on the same host?).


Of course the safest method would be writing a little interpreter in
Erlang itself, but I think the compilation to BEAM (or using Hipe) is a
much better approach. Speed shouldn't be a concern -- especially because
this is just a toy project of mine -- but I just don't want it to be
slow or lets say slower as it could be, even if it is just a constant
factor.

--
Matthias Kretschmer