Re: Argh! Module system frustration.

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <address@hidden> writes:

    Marius> Rob Browning <address@hidden> writes:
    >> Marius Vollmer <address@hidden> writes:
    >> 
    >> > (I'd rather not have people use the module system from C too
    >> much.)
    >> 
    >> Hmm, if you're really deeply integrating guile into a C app,
    >> then I suspect that at least scm_c_module_lookup and perhaps
    >> also scm_c_module_define (though I suspect that a
    >> scm_c_module_set! would be more commonly useful) will probably
    >> often be necessary.

    Marius> Yes, and that's mostly why there is C API to the module
    Marius> system at all.  But I'd like it to be considered
    Marius> `advanced`.

Presumably the "typical" case for doing `define's in C will be in an
init function that is being called via `load-extension'.  And in this
case, (current-module) will already be the Scheme module that calls
`load-extension', which is probably where you want your primitives to
be.  So you typically don't need scm_c_module_define; you can use
scm_c_define instead.

Is that right?

    Marius> Hmm, well, that's not a very constructive position.  I
    Marius> think I'm going to write some paragraphs for the manual of
    Marius> how we intent people to use libguile with C programs, both
    Marius> for adding an extension language to an existing
    Marius> application, and for writing extensions to Guile itself,
    Marius> that will then be the basis for applications written in
    Marius> Scheme.

We should coordinate, as

- I've recently added some discussion to the manual that is quite
  close to this subject, and was planning to continue this discussion.
  See the `Programming Options' node (doc/ref/program.texi in CVS
  unstable) for what's there already.

- The general area of modules and variables etc. is also high on my
  list of doc to work on next.  (In fact I was planning to do this
  tonight, but now I'll wait a bit!)  This priority is motivated by
  the frequency of related questions on the mailing list.

Regards,
        Neil