Re: Creating modules from C

[Marius Vollmer]

Matthias Koeppe <address@hidden> writes:

> Even a very thin layer of C code would help a lot here; I would
> suggest adding a function `scm_module_export_x(SCM module, SCM
> list_of_symbols)' to `modules.h'.  What do others think?

Yes.

I have totally underestimated the cruftiness of the module system
interface from C when I gave my suggestions, sorry.

When I deprecated the automatic dynamic linking of C code for modules,
one goal was to keep C code free from explicit module system
operations.  All the module stuff was to happen from Scheme, with
`define-module', `export', etc.


Ok.  It's "Drastic Measures Time".  [Thinking as I type...] People
should be able to handle modules from C, in a way mostly similar to
how they do it from Scheme.  We don't want to guarantee the lower
level module operations to be stable, but the higher level ones should
be OK for quite some time (even when we get a totally new module
system, I hope that we can find a way to integrate the higher level
features in a backward compatible way).

The higher level interface to the module system consists of

  - define-module MOD-NAME

  - use-modules MOD-NAME...

  - export NAME...

  - the concept of the `current module'

plus, for C only

  - module-lookup MODULE NAME

  - module-define MODULE NAME VAL


So, we should scrap all we have as a C interface to modules right now,
and replace it with:

  - SCM scm_c_define_module (const char *mod_name, void (*init)(void *));

    Define a new module named MOD_NAME and make it current while INIT
    is called.  Return the module.

    MOD_NAME is a string with the list of symbols that make up the
    module name, separated by spaces.  For example, `"foo bar"' names
    the module `(foo bar)'.

    When there already exists a module named MOD_NAME, it is used
    unchanged, otherwise, a empty module is created.

  - SCM scm_c_call_with_current_module (SCM module, void (*func)(void *));

    Call FUNC while MODULE is made current.

  - SCM scm_current_module ();

    Return the module that is currently current.

  - SCM scm_c_use_module (const char *mod_name);

    Add the module named MOD_NAME to the uses list of the current
    module.

  - SCM scm_c_export (const char *NAME, ...);

    Add the bindings designated by NAME... to the public interface of
    the current module.  The list of names is terminated by `NULL'.

  - SCM scm_c_module_lookup (SCM module, const char *NAME);

    Lookup the variable designated by NAME in MODULE.  Throw an error
    when it isn't found.

  - SCM scm_c_module_define (SCM module, const char *NAME, SCM value);

    Insert a new binding into MODULE, named NAME, and initialize it
    with VALUE.  Return the corresponding variable.

  - SCM scm_variable_ref (SCM var);
  - SCM scm_variable_set_x (SCM var, SCM val);

    To work with variables.

  - Additionally, the snarfer puts its definitions into the current
    module.  (Like it does now.)


Ok?  I'd like to do that after merging my vcell cleanup branch.  (It
already contains scm_c_module_lookup and scm_c_module_define...)


Additionally, I think we might want to formalize the concept of a
`Guile Extension', which is some body of compiled code with a
initialization procedure.  No relation to modules.  We could then have
something like

    (define-module (foo bar))

    (load-extension "libguile-foo-bar" :init "foo_bar_init")

    (export ...)

`load-extension' would call dynamic-link and dynamic-call as
appropriate, and coudl also consult a extension registry for
statically linked extensions.