Child modules draft feedback wanted
Mon Apr 3 12:20:19 CEST 2006
Thomas Lindgren wrote:
> <> wrote:
> > More generally, I was considering the transformation
> > of every
> > statement where a module name is specified
> > statically as an atom
> > in a module's beam op. External calls fit into that
> > category,
> > but external calls don't.
Sorry. Please read: External calls fit into that category, but
implicit applies don't.
> > And a new pseudo-BIF could be generated by the
> > compiler:
> > required_module_name(Atom) -> Atom
> > To do the translation at runtime. The parameter to
> > that function
> > must be a statically determinable atom (a "logical
> > module
> > name"), e.g. as in call:
> > ReqlName = required_module_name(logical_name)
> This, or a similar, transformation is also needed when
> one renames, merges, splits, etc. modules in a
> compiler. When an atom is resolved to a module, an
> extra lookup is performed to dispatch to the right
> code. The lookup can be done by the compiler in a
> regular erlang system. (See my paper for EUC 2001.)
This explains simply why external calls are so faster than
> It is, as noted, basically a consequence of passing
> around atoms and then using them as module names. One
> option for Erlang-2 (because not backwards compatible)
> would be to instead have first-class modules:
> M = module lists
> which resolves M to the module named by 'lists'.
> Coupled with a more sophisticated notion of "module"
> and code change (and delving into the requirements and
> details some more), it might serve as the next
> stepping stone.
Actually, using program transformation, it would be possible to
make current beam files compatible with this future "beam-ng",
by inserting beam ops that are calls to such explicit
translation functions (or are just new special conversion ops?),
just before any beam ops that require modules instead of atoms.
More information about the erlang-questions