Re: module loading

[Marius Vollmer <mvo@zagadka.ping.de>]

Mikael Djurfeldt <mdj@nada.kth.se> writes:

> Aleksandar Bakic <bakicale@cps.msu.edu> writes:
> 
> > I noticed this problem a month ago. Mikael Djurfeldt sent me boot.scm
> > that he patched, but now I am not sure if I can use it because the
> > ice-9 directory has been reorganized. Namely, if I define a module
> > using scm_register_module_xxx("pgrt vo", scm_vo_init) and dynamic
> > linking, _and_ have Scheme file ${SCHEME_LIBRARY_PATH}/pgrt/vo.scm, I
> > want them to be loaded both when I write `(use-modules (pgrt
> > vo))'. However, only the C part is loaded; I have to use `(load
> > ".../pgrt/vo.scm")' afterwards in order to get both. If there is no C
> > part but only Scheme one, it works.
> > 
> > Has something changed in the way modules are loaded or this is still a
> > bug?
> 
> I made the patch directly in the repository, so the current snapshot
> behaves the way you want.  I only sent you boot-9.scm so that you
> could start working directly.
> 
> Best regards,
> /mdj

If I remember correctly (and read the ChangeLogs right), Mikael
changed the dynloading behaviour so that a Scheme file in the load
path can not shadow an already registered c-module.  (C-modules are
the ones that are brought into action with scm_register_module_xxx.)

That is, he only made the sequence of the sources that are probed for
modules more intuitive.  Guile still stops at the first found source
(be it an already registered module, a Scheme source file or a shared
library) and use that to provide the module.

What you seem to want, is to have Guile find and merge *all* possible
sources into one module.  If there is both a shared library and a
Scheme source file that could provide the module, you want them to be
*both* activated and merged.  Right?

I don't think that we want this in general.  Being able to shadow
files further down the load-path is a useful feature I think, and
silently merging modules will probably cause more trouble than silent
shadowing.  And searching the load-path for every possible source for
a module (and not stopping at the first match) would probably make
Aubrey throw up his hands in terror.

But not all is lost.  I recently wanted to merge a Scheme file and
c-module myself (for guile-gtk), and here is how I did it:

    (define-module (toolkits gtk)
      :use-module (toolkits gtkstubs)
      :use-module (event-repl))

    ;; Merge the C stubs from their own module

    (define (merge-exports module interface)
      (let ((mod-i (module-public-interface module)))
	(module-for-each (lambda (sym var)
			   (module-add! mod-i sym var))
			 interface)))

    (merge-exports (current-module)
		   (or (resolve-interface '(toolkits gtkstubs))
		       (error "gtkstubs module not found")))

    ;; The default Gtk repl

    ...

The user of guile-gtk is supposed to use the (toolkits gtk) module to
have access to the Gtk toolkit.  Most of this functionality is
contained in a C library, but I wanted to write some things in Scheme.

So I told the library to put its exported functions into a `helper'
module (toolkits gtkstubs) and used the low-level module system to
merge it into the (toolkits gtk) module.