Re: [d.love@dl.ac.uk: dynamic loading of native code modules]

[Neil Jerram <neil@ossau.uklinux.net>]

>>>>> "Thien-Thi" == Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

    Thien-Thi> guile-1.4 supports extending module name semantics to allow mapping also
    Thien-Thi> to .so in addition to .scm files (albeit low level uses dyn* directly --
    Thien-Thi> could use update (patches welcome)).  1.6 does not at the moment (it was
    Thien-Thi> removed).  grep "dyn" reveals 1537 hits since 2000-01.  anyone have

grep "dyn" where?

    Thien-Thi> specific pointers for removal rationale?  where is that refbot?

I think just that the scm_init_xxx - scm_register_module_xxx -
scm_init_module_xxx was thought rather awkward, and that too much of
the boot-9.scm code was trying to be cleverer than it could justify.
I recall an email from Marius saying this, but I don't have a specific
pointer.

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

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

Yes, I think this would be good, actually, and that the
mechanism/hooks that you suggest are exactly the right approach.

The description you gave of the Emacs patch glossed over one detail -
what's the name of the function that gets called to initialize the
dynamically loaded module?  I think it would be acceptable to derive
it algorithmically from the module name (and obviously impose this as
a requirement on the module coder).

If we can agree this, it would be good to do it in 1.6, for
continuity.  (Of interface, I mean; module coding would change
slightly, as just stated.)

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

Sounds orthogonal to me; is it?

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

Upon reflection, I agree.

More generally, looking back through mailing list history, it's
actually astonishing how much support for various stuff that Guile has
_lost_ along the way.  My overall impression is that we (collectively)
have been too glib about this.

        Neil




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel