address@hidden: dynamic loading of native code modules]

[Thien-Thi Nguyen]

   From: Dave Love <address@hidden>
   Subject: dynamic loading of native code modules
   Date: 10 Apr 2002 23:22:27 +0100
   To: address@hidden
   
   This patch for Emacs 21.1 basically extends `load' to allow loading
   compiled C modules and provides a script to build them.  See also the
   attached README.
   
   [...]
   
   * Features
   
   These changes add the ability to dynamically load modules coded in C,
   like the Emacs interpreter core using Libtool facilities.  This works
   just by extending `load' to accept file names with extension `.la'
   which describe Libtool-built modules.  These are found on `load-path',
   like Lisp files, taking precedence over Lisp of the same base name if
   an extension isn't specified.  They work with `require' (if the module
   provides a feature) and `eval-after-load' (should that ever be
   useful).  They can't be loaded from remote filesystems.  There is a
   feature test `dynamic-modules-p' added for the facility, but I'm not
   sure that's actually useful.  Modules can only be loaded once and
   cannot be unloaded; it may be possible to remove these constraints.
   The script `build-emacs-module' cans the Libtool and doc-snarfing
   steps for building modules from source.
   
   XEmacs has a rather more complicated native code module system.  I'm
   not sure the complication is necessary, and it doesn't build on
   libtool.  (Bill Perry, who did the original XEmacs implementation,
   agrees that using Libtool is the right thing.)
    
   [...]

guile-1.4 supports extending module name semantics to allow mapping also
to .so in addition to .scm files (albeit low level uses dyn* directly --
could use update (patches welcome)).  1.6 does not at the moment (it was
removed).  grep "dyn" reveals 1537 hits since 2000-01.  anyone have
specific pointers for removal rationale?  where is that refbot?

it is possible to provide support again in `resolve-interface', but this
support should not be put in boot-9.scm.  instead, resolve-interface
ought to add a user hook somewhere, or be tunable in some other way.
this allows users to customize their concept of "interface" in a
well-defined environment (entirely :-) suited for such customization.
instantiable modules can be supported, etc.

in parallel w/ this change is of course revival of (use-modules FOO)
possibly resolving to .../libfoo.so.x.y.z, using the above hook and the
modern load-extension interface.  the previous mapping proc needs
rationalization and some design to keep weird use-cases in check.

another runner in the race is replacing lowest levels of the module
system w/ environments, using the above hook (or similar internal hook)
for implementation.  getting load-extension and environments together,
basically.

these all are branches that can be pursued relatively independently
after discussion yields a design.  in the end, they are all part of
defining the execution model, if i understand that term correctly, and
moving things to "user space" is what it's all about (slack!).

alternatively, we need to document *why* 1.6 chooses to rob the users
so, at least to ourselves.  "This has been found to be too tricky, and
is no longer supported" is, although not dis-honest, still pretty lame.

thi