BEAM documentation (was Re: Packages in Erlang...)

Luke Gorrie luke@REDACTED
Mon Sep 15 15:16:31 CEST 2003

"Erik Stenman" <Erik.Stenman@REDACTED> writes:

> Hence you are faced with three options:
>  1. Reimplement all the BIFs yourself to work with your system.
>     It is a major undertaking to get all of them working (If 
>     you take a look at other Erlang implementations (e.g., ETOS 
>     and Gerl) you will see that it is in the support of all these 
>     BIFs that these systems lack. It just takes to much time to 
>     reimplement all this and get it bug free.

This may well be the understatement of the century, but: is it really
so much work? :-)

It "seems" like most of it should be quite easy in an ETOS-like
implementation. It should be mostly wrappers for: numbers and maths,
lists, vectors, garbage collection. Processes are free in the sense
that they're fun rather than work :-). That leaves basically ETS, code
loading, ports, debugging, and some miscellany. I can certainly
believe it's hard, but I wouldn't have thought it so much harder than
the HiPE approach?

I must emphasise that I'm not pretending to know that it isn't harder,
I'm just saying that in my stupidly brief perusal I don't understand
why it is :-)

Also I think the real reason ETOS is so incomplete is that they
weren't aiming to do a full implementation, rather they focused on a
minimal one for running benchmark'ey programs. That's how it looks in
the version they distribute sources to at least -- e.g. they skipped
implementing EXIT signals even though they're ultra-fundamental and
not difficult to implement.

(BTW, Does anyone know why the ETOS guys only distribute the source to
version 1.4 even though they have binaries of version 2.3 up? They
don't answer my mail..)

Aside from the BIFs, another issue is linked in drivers. Do you know
how separable those are? In practice do you need to link some of them
with BEAM'ey libraries or similar?


More information about the erlang-questions mailing list