Child modules draft feedback wanted

[Romain Lenglet]

Thomas Lindgren wrote:
> <rlenglet@REDACTED> 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 
implicit applies...

> 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.

-- 
Romain LENGLET