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

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

>>>>> "Rob" == Rob Browning <rlb@defaultvalue.org> writes:

    Rob> Neil Jerram <neil@ossau.uklinux.net> writes:
    >> 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).

    Rob> Some of the higher level abstractions and flexibility sound
    Rob> good, but I'm a little concerned about automatically
    Rob> generating the init function from the module name -- this
    Rob> makes it hard (as I mentioned before) to create modules that
    Rob> share the same C lib or modules that require multiple C libs.
    Rob> It may also make it difficult to easily wrap up existing libs
    Rob> without having to create unnecessary "dummy stub" libs, and
    Rob> feels a little like overspecification.

Ah yes, I remember the discussion now.

    Rob> Of course this would only be a problem if it was the *only*
    Rob> interface.  If we also provided a flexible enough low-level
    Rob> interface for loading shared libs, then having a more
    Rob> automagic, optional higher-level interface might be fine.

I'm pretty sure that Thi was wanting to reinstate (use-modules ...)
support _in addition to_ keeping load-extension and dynamic-call etc.

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

    Rob> My current plan is for 1.8 to have versioned scheme level
    Rob> modules (i.e. use-modules modules), and some workaround that
    Rob> allows for versioned dynamic-link'ing (in part to avoid
    Rob> libtool problems with installations of multiple guile
    Rob> versions), so I don't think there's much chance for seamless
    Rob> continuity between 1.6 and 1.8 anyway.  Given that, I don't
    Rob> think it's worth holding up 1.6 for this, and in truth, my
    Rob> personal feeling (given my experiences with the module system
    Rob> and shared libraries while working on gnucash, g-wrap,
    Rob> mainstream guile, and other projects) is that the current 1.6
    Rob> system is a lot easier to follow.  In the normal case, by
    Rob> looking at one .scm file, you know exactly what's going on,
    Rob> and what's part of a module's interface.

    Rob>   (define-module (foo bar))
    Rob>   (dynamic-call "my_init_func" (dynamic-link "libmylib"))
    Rob>   (export func1)
    Rob>   (export func2)
    Rob>   ...

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?

If it is, then that's probably sufficient for 1.6, and I'll add
something to the docs to make that clear.

    Rob> (load-extension might also (should?) be used here).  To me
    Rob> this code is *really* clear, but other people's mileage may
    Rob> vary :>

Yes, load-extension should be used here.  The difference is that
load-extension provides a way of handling the case where the LIB is
already statically linked in.  (And the case where it has previously
been dynamically linked?)  I think the code is still pretty explicit:

(load-extension "libmylib" "my_init_func")

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

    Rob> I guess I'd have to disagree here too.  Most of the stuff that I can
    Rob> think of that we've "lost" actually makes guile cleaner and less
    Rob> confusing to me, and the stuff that we've added (or are adding) makes
    Rob> guile much more useful.  As examples of things we've done or planned
    Rob> since 1.4:

    Rob>   drop gh_* -> less confusing

    Rob>   add documentation for scm_* -> more useful.

    Rob>   add goops -> *much* more useful

    Rob>   adding GMP -> (for bignums -- on the way to rationals?) more useful

    Rob>   fixing libtool versioning issues -> more useful (more packagable)

    Rob>   planning to drop certain macro "flexibility" so we can support a
    Rob>   clear evaluation model and perhaps eventually support compilation ->
    Rob>   more useful.

    Rob> etc., but do you have particular things you think we've dropped that
    Rob> have actually hurt substantially?

    Rob> Overall I think guile may have (had?) a bit of excess baggage, and
    Rob> I've felt like there's likely to be a decent amount of pruning,
    Rob> pruning which should make guile stronger, before it becomes the
    Rob> extension languge (and perhaps often scheme implementation) of choice
    Rob> if it *is* going to.  I guess rightly or wrongly I've been considering
    Rob> 1.6 and 1.8 to be fairly serious "housecleaning" releases...

Well, I agree with all the examples you give here, but what about the
following?

- dropped support for multibyte strings  [unless I'm misunderstanding
  the old mailing lists, Guile used to have these !]

- dropped/lost support for Tcl/Tk

- dropped/lost support for Ctax and other things (parser, rx etc.)
  in the guile-lang-allover package (or guile-rgx-ctax in CVS)

- dropped/lost support for Hobbit compilation

Now, apart from multibyte strings, none of these should be in the core
(and I haven't checked whether they were ever distributed as such).
Most of the examples here are to do with compatibility of Guile core
with its surrounding packages, and so shouldn't conflict with the
wonderful pruning/cleanups that have been going on in the last couple
of years (and which I totally support).  So how did we lose them?

I shall resist the temptation to quote Lady Bracknell.

        Neil


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