Abstract modules - take 'em for a spin!

[Richard Carlsson]

Ulf Wiger (AL/EAB) wrote:
> So, in your paper, there's a chapter (8) with 
> "Implementation Notes". How much of that has actually
> been done?

All the functionality is there. Calls on the
form 'M:F(...)', i.e., with known arity, are much
faster than before regardless of whether M is an
atom or an abstract module. (Previously, they were
just compiled into calls to erlang:apply/3, which is
slower since the arguments must be put in a list.)

However, apply/3 also works with abstract modules,
although spawn/3 does not seem to work yet.
(You can use 'spawn(fun () -> M:F(...) end)' to
get around this, at least for now.)

There is currently no caching of previously
looked-up pointers, but that is a fairly simple
thing to add later if even more speedup is needed.

Abstract modules are marked as if containing the
attribute '-abstract(true).'.

*Do not* assume that the representation of abstract
modules is known (currently a simple tuple). A new
proper datatype might be added later, as was done
with funs.

	/Richard