Re: address@hidden: dynamic loading of native code modules]

[Neil Jerram]

>>>>> "Rob" == Rob Browning <address@hidden> writes:

    >> Using this kind of approach, is it always possible to emulate the
    >> effect of the old use-modules behaviour by installing a .scm file
    >> that loads the required library?

    Rob> More or less, the primary differences that I can think of are that in
    Rob> the old approach you would put the shared libs in a /usr/share
    Rob> directory (which isn't quite right according to the FHS and causes
    Rob> problems on shared NFS volumes which expect only arch-independent data
    Rob> in /usr/share), where with the new approach the libs need to be
    Rob> located somewhere that libltdl can find them (system lib path,
    Rob> LD_LIBRARY_PATH or LDTL_LIBRARY_PATH).  Also with the old approach,
    Rob> any functions defined in your shared lib would automatically and
    Rob> unavoidably be exported from the module that the shared lib
    Rob> represented -- with the new approach you need to either add an export
    Rob> for each function to the .scm file by hand, or write some module code
    Rob> to export all symbols defined in the module after the shared lib has
    Rob> been initialized -- i.e.

    Rob>   (for-each
    Rob>     (lambda (sym) (export sym))
    Rob>     (module-bindings (current-module)))

    Rob> or similar...

In summary, then, if a module author previously packaged his/her
library so that it could be loaded by (use-modules (pkg whatnot)),
there is a way that he/she can continue to make (use-modules (pkg
whatnot)) work in 1.6.  That sounds OK to me.

    >> - dropped/lost support for Tcl/Tk, [also Ctax etc.]

    Rob> That strikes me as an "add on" that is only going to stick around for
    Rob> as long as there are enough people interested in guile's tcl/tk
    Rob> support to continue maintaining it [...]

    Rob> I guess in the end I feel that in the absence of infinite resources,
    Rob> extensions from the guile core that don't have enough demand to create
    Rob> and sustain the communities that develop and support them often will
    Rob> (and likely should) fade away.

    Rob> Things people want and need *will* get worked on.  [...]

True, but I'm still slightly worried that one of the influences on
{the set of people interested enough to maintain surrounding packages}
might be a gradual trickle of incompatible changes in the core.

So (although I didn't state it clearly before) I guess my point is
that the bitrotting of such modules might be pointing to a problem
that results from an accumulation of small changes like the
use-modules one here.

On the other hand, a project that doesn't change is a dead project,
and packages that can't cope with a small amount of change may not be
worth coddling, and I agree with you that the utility of recent
additions and cleanups far exceeds that of Tcl/Tk and Ctax support.

    >> - dropped/lost support for Hobbit compilation

    Rob> This one I've talked to Marius about off and on at some length, and
    Rob> have actually worked on a bit myself (Hobbit and CVS in particular).
    Rob> I think the conclusion was that guile's evaluator needs to be reworked
    Rob> in some of the ways that Marius, Lynn, and others, including myself
    Rob> have talked about, or any work on compilation is likely to be way too
    Rob> much effort for too little gain.  Guile is not currently built to
    Rob> support compilation cleanly -- the addition of syntax-case and the
    Rob> ways in which it breaks hobbit (among other things) points this out.

    Rob> As Marius has mentioned we likely need a cleaner evaluation model
    Rob> (with clear separations between "read time", "compile time", and
    Rob> "execution time" before we're going to be able to make a lot of
    Rob> sustainable headway here.  The good thing is that if we do manage to
    Rob> seprate these things in a resonable way, we may end up with a lot of
    Rob> interesting flexibility wrt to offline-compilation, JIT compilation,
    Rob> byte-compilation, etc.

All very reasonable, and yet... something used to work, and now it
doesn't.  But on this point I'm unqualified to understand what the
issues really were, so I'll shut up now! :-)

        Neil