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

[Rob Browning <rlb@defaultvalue.org>]

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

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

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

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

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

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

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

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

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

  drop gh_* -> less confusing

  add documentation for scm_* -> more useful.

  add goops -> *much* more useful

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

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

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

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

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

Of course - IMO, etc.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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