Child modules draft feedback wanted

Thomas Lindgren <>
Mon Apr 3 10:37:05 CEST 2006

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


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

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.

(NB: Erlang "packages" lack dynamic translation of
module names to modules, which is one reason why they
aren't quite what's needed.)


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the erlang-questions mailing list