Child modules draft feedback wanted

[Thomas Lindgren]

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

???

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

Best,
Thomas


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com