Re: Module hierarchies, aliasing, and dependencies

[Zefram <zefram@fysh.org>]

Peter Stephenson wrote:
>"Bart Schaefer" wrote:
>> Wouldn't it be better to rely on a symbol that's defined *inside* the
>> module to determine whether a module has been loaded?  Similar to the way
>> (provides 'name) works in emacs libraries?
>
>Yes, this sounds better.  That would have fixed [some of] Will's
>difficulties.  Also, I've been wondering for a while how to provide a test
>version of a module under a different name.  This would be a good solution.

There's an issue here, that a module that calls functions from another
module can't be loaded at the dlopen() level (depending on system).
The module dependency system is there to handle this, but it will
have problems with the kind of scheme you describe.  For example,
zsh/deltochar depends on zsh/zle: with dependencies set up right,
zsh/zle will be loaded automatically before zsh/deltochar.  But if you
load zsh/deltochar under the name "local/deltochar" (or just "deltochar",
or anything else) zsh/zle won't be loaded first, and so the load will fail
(unless zsh/zle was already loaded).

There's another issue that on some systems name clashes between symbols
exported by different modules isn't permitted, so every module's boot
function has to be named differently, so we need to know the module's
internal name in order to call any code in it.  Loading under a different
name just won't work on that kind of system (as I mentioned upthread).

We're stuck with this external naming in many respects, at least until we
start putting dependency-type information in the module files themselves,
in a form that can be read without doing a dlopen().  This is something
I've considered before, but not implemented because of concerns about
what various dynamic linkers might accept.  But if we could do it, we
could include in this metadata the name of the module's boot function,
making it possible to load a module under any name on any system.

If we can relax the connection between modules' internal names and disk
names in this way, it would then be feasible to introduce a distinction
between the module file and the logical modules in contains.  We already
have a special-case relaxation of the one-to-one correspondence --
modules linked in to the main executable -- and I can see advantages in
fully generalising it.

-zefram