What replaces scm_register_module_xxx (Doc update?)

What replaces scm_register_module_xxx (Doc update?)

[rm]

Hello,

according to the docs one can put functions defined
in C into a module by writing a custom initialisation
function and registering it with 'scm_register_module_xxx'.
Since this function seems to have been removed from guile,
how am i supposed to put my functions into modules?

 tia Ralf Mattes

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

Re: What replaces scm_register_module_xxx (Doc update?)

[Dale P. Smith]

On Thu, 8 Aug 2002 15:48:24 +0200
rm@fabula.de wrote:

> Hello,
> 
> according to the docs one can put functions defined
> in C into a module by writing a custom initialisation
> function and registering it with 'scm_register_module_xxx'.
> Since this function seems to have been removed from guile,
> how am i supposed to put my functions into modules?

The new method is to use a .scm file that defines the module,
dynamically loads the compiled code, and then exports whatever you need.

Do do this from C you need to use scm_c_define_module and scm_c_export.

-Dale

-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith@altustech.com            | http://cleveland.lug.net
440-746-9000 x339               |

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

Re: What replaces scm_register_module_xxx (Doc update?)

[Dale P. Smith]

On Thu, 8 Aug 2002 10:21:03 -0400
"Dale P. Smith" <dsmith@altustech.com> wrote:

> To do this from C you need to use scm_c_define_module and scm_c_export.

See examples/box-module/box.c for an example.

-Dale
-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith@altustech.com            | http://cleveland.lug.net
440-746-9000 x339               |

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

Re: What replaces scm_register_module_xxx (Doc update?)

[Rob Browning]

"Dale P. Smith" <dsmith@altustech.com> writes:

> The new method is to use a .scm file that defines the module,
> dynamically loads the compiled code, and then exports whatever you
> need.

Right.

  (define-module (foo bar))
  (load-extension "libguile-foo-bar-v-1" "init_guile_foo_bar-v-1")
  (export foo-1)
  (export foo-2)
  (export bar-1)
  ...

Putting the library major version number into the shared lib name
isn't required by the code, but it's highly recommended for now.  This
will keep you from having .la name conflicts and from not being able
to know which version of your lib will get loaded if/when you need to
release libguile-foo-bar-v-2.  i.e. libguile-foo-bar-v-2.so.2.0.0.

This may just be a temporary practice.  It depends on what we figure
out during the 1.7 series regarding dynamic linking.

Hope this helps.

-- 
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-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: What replaces scm_register_module_xxx (Doc update?)

[rm]

On Thu, Aug 08, 2002 at 09:31:51AM -0500, Rob Browning wrote:
> "Dale P. Smith" <dsmith@altustech.com> writes:
> 
> > The new method is to use a .scm file that defines the module,
> > dynamically loads the compiled code, and then exports whatever you
> > need.
> 
> Right.
> 
>   (define-module (foo bar))
>   (load-extension "libguile-foo-bar-v-1" "init_guile_foo_bar-v-1")
>   (export foo-1)
>   (export foo-2)
>   (export bar-1)
>   ...

I think there's a misunderstanding/misconception here (or, better:
in guile's current C api). The 'load-c-functions-through-scheme' 
aproach might be fine and all that's needed as long as we only want
to extend _guile_ (the application) with external libs. But guile
is inteded to be an embedded srcipting language as well (at least that's
what the documentation says). If i want my users to be able to script
some of my applications functionality there's no library i can load
with 'load-extension' -- of course i could put the tiny scm_* wrapper
functions into a dll and have _that_ loaded, but i wouldn't call this 
good design practise (oh, i could 'load-extension' my own application
instead, but that's not really portable ...). Having to provide (and
deploy!) scm file(s) just to be able to put my functions into different
modules feels clumsy. 
BTW, another problem i see (and face in mod_guile): with the above mentioned
approach it seems to be impossible for one dll to provide functions that
go into different modules. 

;; file: foo/strings
(define-module (foo strings))
 (load-extension "libguile-foo-bar-v-1" "init_guile_foo_bar-v-1")
   (export foo-1)
   (export foo-2)
   (export bar-1)

;; file: foo/utils
(define-module (foo utils))
 (load-extension "libguile-foo-bar-v-1" "init_guile_foo_bar-v-1")
   (export foo-4)
   (export foo-5)

Probably doesn't work as expected, or?

 Ralf Mattes

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

Re: What replaces scm_register_module_xxx (Doc update?)

[Dale P. Smith]

On Thu, 8 Aug 2002 18:19:58 +0200
rm@fabula.de wrote:

> I think there's a misunderstanding/misconception here (or, better:
> in guile's current C api). The 'load-c-functions-through-scheme' 
> aproach might be fine and all that's needed as long as we only want
> to extend _guile_ (the application) with external libs. But guile
> is inteded to be an embedded srcipting language as well (at least that's
> what the documentation says). If i want my users to be able to script
> some of my applications functionality there's no library i can load
> with 'load-extension' -- of course i could put the tiny scm_* wrapper
> functions into a dll and have _that_ loaded, but i wouldn't call this 
> good design practise (oh, i could 'load-extension' my own application
> instead, but that's not really portable ...). Having to provide (and
> deploy!) scm file(s) just to be able to put my functions into different
> modules feels clumsy. 

I think it's possible with the (undocumented) scm_c_* functions in
libguile/modules.c.  It looks like this is the first stab at providing a
C interface to the module system.

A problem that I see is that there is no way to tell the snarfing system
which module to put things in.  It's not that big of a problem if you
split up different "modules" into different C files.  In the init
routine for the file, you first call scm_c_define_module, then #include
the .x file, then call scm_c_exports with the names of the symbols you
need to export.

You might want to verify the scm_c_* fucniton names I used.

-Dale

-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith@altustech.com            | http://cleveland.lug.net
440-746-9000 x339               |

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

Re: What replaces scm_register_module_xxx (Doc update?)

[rm]

On Thu, Aug 08, 2002 at 01:59:30PM -0400, Dale P. Smith wrote:
> 
> I think it's possible with the (undocumented) scm_c_* functions in
> libguile/modules.c.  It looks like this is the first stab at providing a
> C interface to the module system.
> 
> A problem that I see is that there is no way to tell the snarfing system
> which module to put things in.  

That was the nice thing about scm_register_module_xxx - the semantic was 
clear: the init function given to it was supposed to set up all the fuctions/
bindings for the module given in the name parameter. As a bonus one got delayed
loading since the init function got only called when the module was 'use'd.

> It's not that big of a problem if you
> split up different "modules" into different C files.

... one of the reasons i started doing this in mod_guile ;-)

>   In the init
> routine for the file, you first call scm_c_define_module, then #include
> the .x file, then call scm_c_exports with the names of the symbols you
> need to export.

I just wanted to veryfy that this appoach is "blessed" -- and maybe point
out a weak spot in the documentation and API.


Ralf 

> You might want to verify the scm_c_* fucniton names I used.
> 
> -Dale
> 
> -- 
> Dale P. Smith
> Senior Systems Consultant,      | Treasurer,
> Altus Technologies Corporation  | Cleveland Linux Users Group
> dsmith@altustech.com            | http://cleveland.lug.net
> 440-746-9000 x339               |
> 
> _______________________________________________
> Guile-devel mailing list
> Guile-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-devel

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

Re: What replaces scm_register_module_xxx (Doc update?)

[Marius Vollmer]

rm@fabula.de writes:

> If i want my users to be able to script some of my applications
> functionality there's no library i can load with 'load-extension'

You can call C functions by other means than by 'load-extension' ;)

If you want to make several modules available to your users with
functions in them that are implemented in C, you can write the thin
Scheme wrapper for each module, but instead of calling load-extension
you directly call a previously registered C function.  Like so

    void
    foo_init_inits ()
    {
      scm_c_define_gsubr ("foo-init-strings-bindings", ...);
      scm_c_define_gsubr ("foo-init-utils-bindings", ...);
    }

    ;; file: foo/strings
    (define-module (foo strings))
    (foo-init-strings-bindings)
    (export foo-1)
    (export foo-2)
    (export bar-1)

    ;; file: foo/utils
    (define-module (foo utils))
    (foo-init-utils-bindings)
    (export foo-4)
    (export foo-5)

There is the fine point of in what module foo-init-strings-bindings is
defined.  I'm not sure about that, right now...

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

Re: What replaces scm_register_module_xxx (Doc update?)

[Neil Jerram]

>>>>> "rm" == rm  <rm@fabula.de> writes:

    rm> I think there's a misunderstanding/misconception here (or,
    rm> better: in guile's current C api). The
    rm> 'load-c-functions-through-scheme' aproach might be fine and
    rm> all that's needed as long as we only want to extend _guile_
    rm> (the application) with external libs. But guile is inteded to
    rm> be an embedded srcipting language as well (at least that's
    rm> what the documentation says). If i want my users to be able to
    rm> script some of my applications functionality there's no
    rm> library i can load with 'load-extension' -- of course i could
    rm> put the tiny scm_* wrapper functions into a dll and have
    rm> _that_ loaded, but i wouldn't call this good design practise
    rm> (oh, i could 'load-extension' my own application instead, but
    rm> that's not really portable ...). Having to provide (and
    rm> deploy!) scm file(s) just to be able to put my functions into
    rm> different modules feels clumsy.

Right now I'm afraid I don't follow the structure of your
extension(s), but it certainly sounds to me like you ought to be able
to achieve what you are trying to.

Could you describe the structure in more detail, in terms of code
modules (C and Scheme), libraries, how things get loaded and
configured, etc.?

        Neil


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

Re: What replaces scm_register_module_xxx (Doc update?)

[Matthias Koeppe]

rm@fabula.de writes:

> On Thu, Aug 08, 2002 at 09:31:51AM -0500, Rob Browning wrote:
>> "Dale P. Smith" <dsmith@altustech.com> writes:
>> 
>> > The new method is to use a .scm file that defines the module,
>> > dynamically loads the compiled code, and then exports whatever you
>> > need.
>> 
>> Right.
>> 
>>   (define-module (foo bar))
>>   (load-extension "libguile-foo-bar-v-1" "init_guile_foo_bar-v-1")
>>   (export foo-1)
>>   (export foo-2)
>>   (export bar-1)
>>   ...
>
> I think there's a misunderstanding/misconception here (or, better:
> in guile's current C api). The 'load-c-functions-through-scheme' 
> aproach might be fine and all that's needed as long as we only want
> to extend _guile_ (the application) with external libs. But guile
> is inteded to be an embedded srcipting language as well (at least that's
> what the documentation says). If i want my users to be able to script
> some of my applications functionality there's no library i can load
> with 'load-extension' -- of course i could put the tiny scm_* wrapper
> functions into a dll and have _that_ loaded, but i wouldn't call this 
> good design practise (oh, i could 'load-extension' my own application
> instead, but that's not really portable ...). Having to provide (and
> deploy!) scm file(s) just to be able to put my functions into different
> modules feels clumsy. 

Indeed.

I just want to point out that there was a similar discussion back in
May 2001 ("On the deprecated auto-loading of compiled-code modules").
See

    http://mail.gnu.org/pipermail/guile-devel/2001-May/thread.html#1922

Back then, I had complained that I could no longer do module business
from C after scm_register_module_xxx became deprecated.  

After some discussion, Marius wrote
(http://mail.gnu.org/pipermail/guile-devel/2001-May/002171.html):

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

He proposed and implemented a C API for defining modules and exporting
symbols, see

    http://mail.gnu.org/pipermail/guile-devel/2001-May/002171.html

I use this API in the Guile back-end of SWIG (http://www.swig.org).
The functions are also mentioned in the NEWS file of Guile (changes
after release 1.4).  The API is also used in
examples/box-module/box.c.

I believe it's only an accident that the functions are not documented
(except for the NEWS blurb).  I think documentation should be added;
the changes should also go into the 1.6 release.  Preliminary
documentation can be found in the above message by Marius.

Regards,

-- 
Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe

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

Re: What replaces scm_register_module_xxx (Doc update?)

[rm]

On Fri, Aug 09, 2002 at 10:47:50AM +0200, Matthias Koeppe wrote:
> [...]
> 
> He proposed and implemented a C API for defining modules and exporting
> symbols, see
> 
>     http://mail.gnu.org/pipermail/guile-devel/2001-May/002171.html
> 
> I use this API in the Guile back-end of SWIG (http://www.swig.org).
> The functions are also mentioned in the NEWS file of Guile (changes
> after release 1.4).  The API is also used in
> examples/box-module/box.c.

Ah, thank's a lot, the "missing files". I remembered the discussion
but forgot that Marius _did_ post a description of the new interface.
Marius, just one more question: it looks like the signature of 
scm_c_define_module changed slightly since your mail back last may:

 scm_c_define_module (const char *name,
                      void (*init)(void *), void *data)

 - what is the purpose of 'void *data' ?

 - what is passed to the init function in the void pointer and
   what is the function supposed to return?

> 
> I believe it's only an accident that the functions are not documented
> (except for the NEWS blurb).  I think documentation should be added;
> the changes should also go into the 1.6 release.  Preliminary
> documentation can be found in the above message by Marius.

Should this be documented soon?

  Ralf


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

Re: What replaces scm_register_module_xxx (Doc update?)

[Matthias Koeppe]

rm@fabula.de writes:

> On Fri, Aug 09, 2002 at 10:47:50AM +0200, Matthias Koeppe wrote:
>> [...]
>> 
>> He proposed and implemented a C API for defining modules and exporting
>> symbols, see
>> 
>>     http://mail.gnu.org/pipermail/guile-devel/2001-May/002171.html
>> 
>> I use this API in the Guile back-end of SWIG (http://www.swig.org).
>> The functions are also mentioned in the NEWS file of Guile (changes
>> after release 1.4).  The API is also used in
>> examples/box-module/box.c.
>
> Ah, thank's a lot, the "missing files". I remembered the discussion
> but forgot that Marius _did_ post a description of the new interface.
> Marius, just one more question: it looks like the signature of 
> scm_c_define_module changed slightly since your mail back last may:
>
>  scm_c_define_module (const char *name,
>                       void (*init)(void *), void *data)
>
>  - what is the purpose of 'void *data' ?

It is an opaque argument...

>  - what is passed to the init function in the void pointer and
>    what is the function supposed to return?

... that is simply passed to the init function when it is invoked.
(This makes the init function a "C closure".)  The init function
returns nothing (it has "void" return type).

>> I believe it's only an accident that the functions are not documented
>> (except for the NEWS blurb).  I think documentation should be added;
>> the changes should also go into the 1.6 release.  Preliminary
>> documentation can be found in the above message by Marius.
>
> Should this be documented soon?

Ralf, maybe you want to prepare a patch that adds the documentation to
Guile. 

Regards,

-- 
Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe

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

Re: What replaces scm_register_module_xxx (Doc update?)

[rm]

On Fri, Aug 09, 2002 at 01:29:09PM +0200, Matthias Koeppe wrote:
> 
> It is an opaque argument...
> 
> >  - what is passed to the init function in the void pointer and
> >    what is the function supposed to return?
> 
> ... that is simply passed to the init function when it is invoked.

So this is "userdata", i see.

> (This makes the init function a "C closure".)  The init function
> returns nothing (it has "void" return type).

<blush>Grumpf! I _hate_ C's function pointer syntax ... </blush>

> >> I believe it's only an accident that the functions are not documented
> >> (except for the NEWS blurb).  I think documentation should be added;
> >> the changes should also go into the 1.6 release.  Preliminary
> >> documentation can be found in the above message by Marius.
> >
> > Should this be documented soon?
> 
> Ralf, maybe you want to prepare a patch that adds the documentation to
> Guile. 

This was partly implied by my question. But i first need to finish up
the docs on "guardians from C" i promised earlier this week (got dis-
tracted by all that module stuff which i need to get working asap).

  Ralf

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

Re: What replaces scm_register_module_xxx (Doc update?)

[rm]

On Thu, Aug 08, 2002 at 10:28:08PM +0100, Neil Jerram wrote:
> 
> Right now I'm afraid I don't follow the structure of your
> extension(s), but it certainly sounds to me like you ought to be able
> to achieve what you are trying to.

Well, my extension isn't -- it's an application (Apache in this special
case, but i think the problem is a general one).

> Could you describe the structure in more detail, in terms of code
> modules (C and Scheme), libraries, how things get loaded and
> configured, etc.?

Apache (the application) loads mod_guile (an apache module). mod_guile
registers some callback functions with apache. Apache then calls theses
functions whenever it thinks that a certain part of a request (authrntication,
authorization, URL-rewrite, content delivery etc.) should be handled by
guile (as can be customized in apaches configuration file). mod_guile then
calls the function that is supposed to handle this part of a request
(again, the module and name of the function can be specified in the server
configuration files). To ba able to do something usefull, these functions
need to be able to access the data structures of the server/request.
Each hander function is passed a request-record structure (a SMOB arround
apaches 'real' datastructure) as a parameter - this structure has fields
that point to the server and connection record structures as well. 
Since all of these structures have quite a lot of fields we end up with
a lot of functions (getters/setters). All of these functions are defined
in mod_guile but of course should go into separate guile modules. Right
now (as you can see, i got it working ;-) the following modules are 
defined: (apache request), (apache server), (apache connection),
(apache tables), (mod-guile utils).


 Ralf Mattes

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

Re: What replaces scm_register_module_xxx (Doc update?)

[Marius Vollmer]

rm@fabula.de writes:

> Should this be documented soon?

Will do.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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

Re: What replaces scm_register_module_xxx (Doc update?)

[Marius Vollmer]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> rm@fabula.de writes:
> 
> > Should this be documented soon?
> 
> Will do.

Ok, I started but I got distracted into writing don yet another module
system proposal.  Please have a look.  It is not finished, but I think
one can already see where it is heading.  It is based on
scheme-modules.texi.


@node The Guile module system
@section The Guile module system

The Guile module system extends the concept of environments, discussed
in the previous section, with mechanisms to define, use and customise
sets of bindings.

In 1996 Tom Lord implemented a full-featured module system for Guile which
allows loading Scheme source files into a private name space.  This system has
been in available since at least Guile version 1.1.

For Guile version 1.6.0 and later, the system has been improved to have better
integration from C code, more fine-grained user control over interfaces, and
documentation.

Although it is anticipated that the module system implementation will
change in the future, the Scheme programming interface described in this
manual should be considered stable.  The C programming interface is
considered relatively stable, although at the time of this writing,
there is still some flux.

The following sections will explain the Guile module system in detail,
from an interactive point of view.  That is, the behavior of the
module system is defined in terms of run-time data structures and the
operations on them.  The operations include the high-level ones like
@code{define-module} that are used more like declarative statements as
well as lower level operations like @code{module-lookup}.

@c fixme: Review: Need better C code interface commentary.

@menu
* Finding Modules::             How modules are found.
* General Information about Modules::  Guile module basics.
* Using Guile Modules::         How to use existing modules.
* Creating Guile Modules::      How to package your code into modules.
* More Module Procedures::      Low-level module code.
* Module System Quirks::        Strange things to be aware of.
* Included Guile Modules::      Which modules come with Guile?
@end menu

@node Finding Modules
@subsection Finding Modules

A Guile module is a data structure with the features described in the
following sections.  You can work directly with the data structure in
your programs, but normally you refer to them indirectly via the
familiar hierachical names like @code{(ice-9 popen)}.

There is a global mapping from names to module objects.  You can
manipulate this mapping with the settable function @code{find-module}.
You can find the name of a module with the function
@code{module-name}.

Normally, modules are created as a side-effect of loading and
executing a file.  The file might contain a @code{define-module} that
will install a new module, or it might not.  Thus, files and modules
are only loosely coupled.  However, there is a convention that maps
module names to file names and this convention allows Guile to
automatically load and execute a file when a certain module is
requested but has not been registered yet.

The function @code{load-module} implements this mapping and
@code{resolve-module} is an extended version of @code{find-module}
that uses @code{load-module} for missing modules.  Thus,
@code{resolve-module} is the most common function to use when looking
for a module.

@deffn Procedure find-module name
@deffnx Setter (set! (find-module name) module)
The procedure @code{find-module} returns the module that has most
recently been registered with the name @var{NAME}.  When no module has
been registered under @var{NAME}, return @code{#f}.

Note that @code{find-module} will not automatically load modules.  Use
@code{resolve-module} or @code{load-module} for that.

Setting this procedure will register @var{module} under the name
@var{name}.  When @var{module} is @code{#f}, any registration for
@var{name} is removed.

A @var{name} must be a list of symbols like @code{(ice-9 popen)}.

When a module is registered, the name is remembered in it so that
@code{module-name} can return it.  When a module is removed from the
global mapping (because it is replaced by another module or by
@code{#f}), its remembered name is not changed.
@end deffn

@deffn Procedure module-name module
@deffnx Setter (set! (module-name module) name)
Return the remembered name of @var{module}.  This is not necessarily
the name that can be used to find this module with @code{find-module}.
See @code{find-module} for details.  The initial name of a module is
@code{#f}.

Setting this procedure will change the remembered name.  It will not
change the global mapping that is consulted by @code{find-module}.

The remembered name of a module is mostly intended for debugging
purposes.
@end deffn

@deffn Procedure load-module name
Load the file that is supposed to define the module named by
@var{name}, a list of symbols.

The name of the file to load is constructed by concatenating the name
elements with slashes between the elements and appending a number of
file name extensions from the list @code{%load-extensions}
(@pxref{Loading}).  The resulting file name is then searched in all
directories in the variable @code{%load-path} (@pxref{Install
Config}).  For example, the @code{(ice-9 popen)} module would result
in the filename @code{ice-9/popen.scm} and searched in the
installation directories of Guile and in all other directories in the
load path.  The first file that is found by the above procedure is
loaded.  When no file is found, signal an error.

After the the file is loaded, the result of @code{(find-module
@var{name})} is returned when it is non-@code{#f}.  Else signal an
error.
@end deffn

@deffn Procedure resolve-module name
Find the module named @var{name}, loading it via @code{load-module}
when it is not yet registered.  When the module can not be found,
signal an error.
@end deffn


@node General Information about Modules
@subsection General Information about Modules

A Guile module can be thought of as a collection of named variables
and macros.  More precisely, it is a mapping of symbols (names) to
Scheme objects.  Such an association of a symbol with an object is
also called a @dfn{binding}, and one says that the symbol is
@dfn{bound} to the object in a specific module.  Symbols can only be
bound to two kinds of objects: variables or macro transformers.

This is a crucial point; when you evaluate @code{(define foo 12)} in a
module, then the symbol @code{foo} is not bound directly to @code{12}.
Rather, @code{foo} is bound to a variable (@pxref{Variables}) and the
value of that variable is set to the value @code{12}.  Likewise, when
you define a macro, the symbol is bound to a macro transformer object
instead of to a variable.  (Actually, Guile wont do the latter
currently, but will do so in the next release.)

@c I think the following paragraph is confusing here, especially
@c given that there are objects called ``envrionments'' in Guile
@c that are really modules. - mvo
@c
@c An environment is a mapping from identifiers (or symbols) to
@c locations, i.e., a set of bindings.  There are top-level environments
@c and lexical environments.  Environment in which a lambda is excuted is
@c remembered as part of its definition.

You can only add to the set of bindings of a module, you can not
remove bindings.  Also, you can only have a single binding for each
symbol in the set.  As a consequence, once you have added a local or
imported binding to a module, it can not be changed.  Attempting to
bind a symbol to the same object that it is already bound to is
silently ignored.

These rules ensure that a module can only evolve in a simple manner.
Once you have looked up a binding in a module, you can be sure that it
remains valid and that all lookups with the same symbol in a module
will return the same binding.  When you need to make changes to a
module that are not allowed by these rules, you must abandon the old
module and create a new one.  Modules that use the old module in some
way need to be reconstructed as well, and so on.  See @pref{FIXME} for
more information about this.

When Guile executes or compiles some code, it does this always in the
context of a module.  That module is called the @dfn{current module}.
Set settable procedure @code{current-module} can be used to access the
current module.  The global identifiers of the executed or compiled
code are looked up by finding the object that is bound to the
identifier symbol in the current module.  In certain contexts, the
object must be a variable so that it can be referenced or set, in
others, it is also allowed to be a macro transformer which is then used
to expand the evaluated form.

Execution of a @code{define} form can add a new variable binding to
the current module.  When the symbol in the @code{define} form is
already bound to a variable, the binding itself is not changed, only
the value of the variable.  When the symbol is bound but not to a
variable, an error is signalled.

Execution of @code{define-macro} works similar, but for macro
transformers instead of variables.

To access bindings from another module, the desired bindings are
simply copied into the accessing module.  There are several ways to
select which bindings to copy exactly and how to transform the symbols
on the way.  Ultimately, however, imported bindings are added just
like local bindings.

You can access all bindings in a module; there are no strictly private
bindings that you are prohibited from accessing.  However, each module
has a list of @dfn{exported symbols} that it offers as its public
interface.  Usually, one just imports the bindings belonging to the
exported symbols.

You can add to the list of exported symbols with an @code{export}
statement.  Symbols can be removed with @code{unexport}.  Changes to
the list of exported symbols have no immediate consequences in other
modules, however.  The list is only consulted at the time of
importing, if at all.


@node Using Guile Modules
@subsection Using Guile Modules

Accessing bindings from another module is called @dfn{using} that
module.  On a low level, it consists of determining which bindings to
access by building a list of symbols that name these bindings in the
accessed module, and building another list of symbols that determine
for each binding under which name it should be recorded in the
accessing module.

The procedure @code{module-import} can then be used to add the new
bindings to the accessing module.  After the bindings have been added
to the module, all memory is lost about where they came from.

A common way of using a module is to just import all exported bindings
with their original names.  This, and also more sophisticated
arrangements, can be conveniently expressed with a @code{use-modules}
statement.  Executing a @code{use-modules} statement may include
locating and loading code for a given module if that code has not yet
been loaded.

An @dfn{interface specification} in a @code{use-modules} statement has
one of two forms.  The first variation is simply to name the module,
in which case its exported bindings are imported with their original
names.  For example:

@smalllisp
(use-modules (ice-9 popen))
@end smalllisp

Here, the interface specification is @code{(ice-9 popen)}, and the
result is that the current module now has access to @code{open-pipe},
@code{close-pipe}, @code{open-input-pipe}, and so on (@pxref{Included
Guile Modules}).

Note in the previous example that if the current module had already
defined @code{open-pipe}, adding the binding from @code{(ice-9 popen)}
would have resulted in an error.  For this reason (and others), there
is a second variation of interface specification that not only names a
module to be accessed, but also selects bindings from it and renames
them to suit the current module's needs.  For example:

@smalllisp
(use-modules ((ice-9 popen)
              :select ((open-pipe . pipe-open) close-pipe)
              :renamer (symbol-prefix-proc 'unixy:)))
@end smalllisp

Here, the interface specification is more complex than before, and the
result is that a custom interface with only two bindings is created and
subsequently accessed by the current module.  The mapping of old to new
names is as follows:

@c Use `smallexample' since `table' is ugly.  --ttn
@smallexample
(ice-9 popen) sees:             current module sees:
open-pipe                       unixy:pipe-open
close-pipe                      unixy:close-pipe
@end smallexample

This example also shows how to use the convenience procedure
@code{symbol-prefix-proc}.

@c begin (scm-doc-string "boot-9.scm" "symbol-prefix-proc")
@deffn {Scheme Procedure} symbol-prefix-proc prefix-sym
Return a procedure that prefixes its arg (a symbol) with
@var{prefix-sym}.
@c Insert gratuitous C++ slam here.  --ttn
@end deffn

@c begin (scm-doc-string "boot-9.scm" "use-modules")
@deffn syntax use-modules spec @dots{}
Resolve each interface specification @var{spec} into a set of bindings
and add them to the current module.  The return value is unspecified.

The first variant of @var{spec} is just

@smalllisp
 MODULE-NAME
@end smalllisp

where @var{module-name} is a list of symbols that names a module whose
exported bindings are added to the current module with their original
names.  The module named by @var{module-name} is loaded as with
@code{resolve-module} when it has not been registered already.

The second variant of @var{spec} is

@smalllisp
 (MODULE-NAME [:select SELECTION] [:renamer RENAMER])
@end smalllisp

As before, @var{module-name} is a list of symbols that is used to find
the module that is to be accessed.  The optional @var{selection}
parameter is a list of selection-specs and the optional @var{renamer}
is a procedure that takes a symbol and returns a new one that should
be used in its place as the name of a binding.  A selection-spec is
either a symbol or a pair of symbols @code{(ORIG . SEEN)}, where
@var{orig} is the name in the accessed module and @var{seen} is the
name in the accessing module.  The symbol @var{seen} is also passed
through @var{renamer}.

When @code{selection} is omitted, it defaults to the list of exported
symbols of @var{module-name}.  When @code{rename} is omitted, it
defaults to the identity function (i.e., the bindings are not
renamed).  Thus, when both are omitted, the effect is the same as with
the first var{spec} form.

A error is signalled when @var{module name} is not resolvable.
@end deffn

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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

Re: What replaces scm_register_module_xxx (Doc update?)

[Marius Vollmer]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> rm@fabula.de writes:
> 
> > Should this be documented soon?
> 
> Will do.

Done.  Please have a look.  (In CVS HEAD.)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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

Re: What replaces scm_register_module_xxx (Doc update?)

[Dirk Herrmann]

Hi, 

I have some comments and questions regarding the text.

On 12 Aug 2002, Marius Vollmer wrote:

> A Guile module is a data structure with the features described in the
> following sections.  You can work directly with the data structure in
> your programs, but normally you refer to them indirectly via the
> familiar hierachical names like @code{(ice-9 popen)}.

I think it would be helpfull to explain that there is no relationship
between modules named (a b) and (a b c).  People might assume that there
is some subset/superset relationship.  Especially since I remember that
once there was such a concept in guile.

> @deffn Procedure find-module name
> @deffnx Setter (set! (find-module name) module)
> The procedure @code{find-module} returns the module that has most
> recently been registered with the name @var{NAME}.  When no module has
> been registered under @var{NAME}, return @code{#f}.

I'd find it clearer when registering a module would be done using a
function 'register-module' instead of using a setter.  And, the
possibility to register a module implies that people can create modules
dynamically.  But, there are no functions described to create modules
dynamically.

> @c I think the following paragraph is confusing here, especially
> @c given that there are objects called ``envrionments'' in Guile
> @c that are really modules. - mvo

Yes, we should attempt to be cleaner with our names.  Environments should
be used for lexical environments.  I also don't like the name 'variable'
since it rather names a location than a variable.  'Location', on the
other hand, is also not quite accurate, since local variables are also
stored in locations, but for these there are no variables.  At least we
should not use names used in R5RS to name concepts which are not exactly
the same.

> @c An environment is a mapping from identifiers (or symbols) to
> @c locations, i.e., a set of bindings.  There are top-level environments
> @c and lexical environments.  Environment in which a lambda is excuted is
> @c remembered as part of its definition.

What is the relationship between modules and top-level environments then?

> You can only add to the set of bindings of a module, you can not
> remove bindings.  Also, you can only have a single binding for each
> symbol in the set.  As a consequence, once you have added a local or
> imported binding to a module, it can not be changed.  Attempting to
> bind a symbol to the same object that it is already bound to is
> silently ignored.

With respect to modules this means that there is no undelete.  Good.  And,
if this also applies to top-level environments, then memoization of
variable locations can be used.

> These rules ensure that a module can only evolve in a simple manner.
> Once you have looked up a binding in a module, you can be sure that it
> remains valid and that all lookups with the same symbol in a module
> will return the same binding.  When you need to make changes to a
> module that are not allowed by these rules, you must abandon the old
> module and create a new one.  Modules that use the old module in some
> way need to be reconstructed as well, and so on.  See @pref{FIXME} for
> more information about this.

Hmmm.  This needs to be clarified, especially with respect to memoized
code.

> When Guile executes or compiles some code, it does this always in the
> context of a module.  That module is called the @dfn{current module}.
> Set settable procedure @code{current-module} can be used to access the
> current module.  The global identifiers of the executed or compiled
> code are looked up by finding the object that is bound to the
> identifier symbol in the current module.  In certain contexts, the
> object must be a variable so that it can be referenced or set, in
> others, it is also allowed to be a macro transformer which is then used
> to expand the evaluated form.

I think this paragraph is incorrect:  Only when guile executes some
top-level expressions the lookups are done in the current module.  In
other words, while executing a top-level expression, the current-module
corresponds to the top-level environment of that expression.  When a
closure is created, is closes over the current top-level environment.  As
soon as a closure is executed, it is executed in the context of the module
that corresponded to the top-level environment at the creation of the
closure.

> Execution of a @code{define} form can add a new variable binding to
> the current module.  When the symbol in the @code{define} form is
> already bound to a variable, the binding itself is not changed, only
> the value of the variable.  When the symbol is bound but not to a
> variable, an error is signalled.

Maybe some clarification would be helpfull:  There are also internal
defines, which are not meant here.

> To access bindings from another module, the desired bindings are
> simply copied into the accessing module.  There are several ways to
> select which bindings to copy exactly and how to transform the symbols
> on the way.  Ultimately, however, imported bindings are added just
> like local bindings.

That means, modifying a value at the location of a binding will also
modify the value for the source module.

> Note in the previous example that if the current module had already
> defined @code{open-pipe}, adding the binding from @code{(ice-9 popen)}
> would have resulted in an error.  For this reason (and others), there
> is a second variation of interface specification that not only names a
> module to be accessed, but also selects bindings from it and renames
> them to suit the current module's needs.  For example:

Ahh.  Conflicting imports will result in errors.  But:  What happens if an
imported binding is overwritten by 'define' in the current module?
According to R5RS, in such a case 'define' becomes 'set!'.  And this would
influence the source module of the definition.  Hmmm.

> The second variant of @var{spec} is
> 
> @smalllisp
>  (MODULE-NAME [:select SELECTION] [:renamer RENAMER])
> @end smalllisp

Can one use the same module several times, every time specifying some
different SELECTION and RENAMER?  Can the same variable be imported
several times under different names?

Best regards,
Dirk



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

Re: What replaces scm_register_module_xxx (Doc update?)

[Neil Jerram]

>>>>> "Dirk" == Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

    Dirk> On 12 Aug 2002, Marius Vollmer wrote:

    >> A Guile module is a data structure with the features described in the
    >> following sections.  You can work directly with the data structure in
    >> your programs, but normally you refer to them indirectly via the
    >> familiar hierachical names like @code{(ice-9 popen)}.

    Dirk> I think it would be helpfull to explain that there is no relationship
    Dirk> between modules named (a b) and (a b c).  People might assume that there
    Dirk> is some subset/superset relationship.  Especially since I remember that
    Dirk> once there was such a concept in guile.

There still is.  In this case, and assuming that both modules have
been loaded, there is a variable named `c' in (a b) whose value is the
module (a b c).

        Neil



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

Re: What replaces scm_register_module_xxx (Doc update?)

[Neil Jerram]

>>>>> "rm" == rm  <rm@fabula.de> writes:

    rm> Apache (the application) loads mod_guile (an apache module). mod_guile
    rm> registers some callback functions with apache. Apache then calls theses
    rm> functions whenever it thinks that a certain part of a request (authrntication,
    rm> authorization, URL-rewrite, content delivery etc.) should be handled by
    rm> guile (as can be customized in apaches configuration file). mod_guile then
    rm> calls the function that is supposed to handle this part of a request
    rm> (again, the module and name of the function can be specified in the server
    rm> configuration files). To ba able to do something usefull, these functions
    rm> need to be able to access the data structures of the server/request.
    rm> Each hander function is passed a request-record structure (a SMOB arround
    rm> apaches 'real' datastructure) as a parameter - this structure has fields
    rm> that point to the server and connection record structures as well. 
    rm> Since all of these structures have quite a lot of fields we end up with
    rm> a lot of functions (getters/setters). All of these functions are defined
    rm> in mod_guile but of course should go into separate guile modules. Right
    rm> now (as you can see, i got it working ;-) the following modules are 
    rm> defined: (apache request), (apache server), (apache connection),
    rm> (apache tables), (mod-guile utils).

OK, so the idea is:

HTTP request for some URL --->
  mapped by Apache config file to generic mod_guile handler,
  with parameters indicating the module in which the appropriate
  handler proc lives, and perhaps the proc name as well (?)

mod_guile handler uses the module and calls the handler proc from that
  module (how do you handle handler procs with the same name in
  different modules? perhaps by not actually importing them)

Now we're into Scheme code, that has a SMOB in its hand and wants to
  use the utility functions defined in (apache request) etc. to play
  with it, which it does using use-module in the usual way.

And the problem was: how do you export the C definitions for (apache
request) etc. into their respective modules?

I presume that Marius's docs for the C module API have given you one
answer, using scm_c_define, scm_c_with_module etc.  Another
possibility would be to write a C function per module to register its
definitions as Guile primitives:

void mg_register_apache_request_primitives ()
{
  scm_c_define_gsubr (...);
  ...
}

Then at the top of apache/request.scm, you can call this using either
load-extension or the dynamic-* functions:

(define-module (apache request)
  ...)

(load-extension "libmg" "mg_register_apache_request_primitives")

Does this cover everything, and would you mind if I reworked this into
another example for the manual?

Regards,
        Neil



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

Re: What replaces scm_register_module_xxx (Doc update?)

[Dale P. Smith]

On 13 Aug 2002 02:40:28 +0200
Marius Vollmer <mvo@zagadka.ping.de> wrote:

> Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
> > rm@fabula.de writes:
> > 
> > > Should this be documented soon?
> > 
> > Will do.
> 
> Done.  Please have a look.  (In CVS HEAD.)

Looks good, but there should be @var{} around the actual names of the
arguments, for example:

@deftypefn {C Procedure} SCM scm_c_define_module (const char *name, void (*init) (void *), void *data)

Should be:

@deftypefn {C Procedure} SCM scm_c_define_module (const char *@var{name}, void (*@var{init}) (void *), void *@var{data})

I've found that you can force texinfo to do line breaks between arguments for long winded functions if you surround them with {}.

@deftypefn {C Procedure} SCM scm_c_define_module ({const char *@var{name},} {void (*@var{init}) (void *),} {void *@var{data}})


-Dale



-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith@altustech.com            | http://cleveland.lug.net
440-746-9000 x339               |


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

Re: What replaces scm_register_module_xxx (Doc update?)

[rm]

On Sat, Aug 17, 2002 at 12:59:47PM +0100, Neil Jerram wrote:
> OK, so the idea is:
> 
> HTTP request for some URL --->
>   mapped by Apache config file to generic mod_guile handler,
>   with parameters indicating the module in which the appropriate
>   handler proc lives, and perhaps the proc name as well (?)

Yes, indeed. On can 'map' a request URL to an module/handler:

| <Location /blub>
|  ...
|  GuileSetHandler (foo bar)
| </Location>

or with an optional handler name:

| GuileSetHanlder ((foo bar) . my-handler) 
 
> mod_guile handler uses the module and calls the handler proc from that
>   module (how do you handle handler procs with the same name in
>   different modules? perhaps by not actually importing them)

Correct, i don't import the modules, i just use them as namespace compartments.

> Now we're into Scheme code, that has a SMOB in its hand and wants to
>   use the utility functions defined in (apache request) etc. to play
>   with it, which it does using use-module in the usual way.
> 
> And the problem was: how do you export the C definitions for (apache
> request) etc. into their respective modules?
> 
> I presume that Marius's docs for the C module API have given you one
> answer, using scm_c_define, scm_c_with_module etc.  Another
> possibility would be to write a C function per module to register its
> definitions as Guile primitives:
> 
> void mg_register_apache_request_primitives ()
> {
>   scm_c_define_gsubr (...);
>   ...
> }

This is how i do it currently. An init function per functional unit/module.

> 
> Then at the top of apache/request.scm, you can call this using either
> load-extension or the dynamic-* functions:
> 
> (define-module (apache request)
>   ...)
> 
> (load-extension "libmg" "mg_register_apache_request_primitives")

Currently i pass these init functions to 'scm_c_define_module', but that's
probably equivalent to your solution.

> Does this cover everything, and would you mind if I reworked this into
> another example for the manual?

Sounds  fine to me. As soon as i get space on a server i'll put the code
online (together with some samples ;-)


Ralf


> Regards,
>         Neil
> 


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

Re: What replaces scm_register_module_xxx (Doc update?)

[Marius Vollmer]

Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

> I think it would be helpfull to explain that there is no relationship
> between modules named (a b) and (a b c).

Yes.

> > @deffn Procedure find-module name
> > @deffnx Setter (set! (find-module name) module)
> > The procedure @code{find-module} returns the module that has most
> > recently been registered with the name @var{NAME}.  When no module has
> > been registered under @var{NAME}, return @code{#f}.
> 
> I'd find it clearer when registering a module would be done using a
> function 'register-module' instead of using a setter.

Hmm, I was experimenting with the way Common Lisp does it.  They have
'find-class' that is also a setter for registering classes.  I don't
know yet whether I like it or not.  The text that I posted is not a
serious proposal, only some loose ideas.

> > @c An environment is a mapping from identifiers (or symbols) to
> > @c locations, i.e., a set of bindings.  There are top-level environments
> > @c and lexical environments.  Environment in which a lambda is excuted is
> > @c remembered as part of its definition.
> 
> What is the relationship between modules and top-level environments then?

They are identical.  (Are they?)

> > You can only add to the set of bindings of a module, you can not
> > remove bindings.  Also, you can only have a single binding for
> > each symbol in the set.  As a consequence, once you have added a
> > local or imported binding to a module, it can not be changed.
> > Attempting to bind a symbol to the same object that it is already
> > bound to is silently ignored.
> 
> With respect to modules this means that there is no undelete.  Good.  And,
> if this also applies to top-level environments, then memoization of
> variable locations can be used.
> 
> > These rules ensure that a module can only evolve in a simple manner.
> > Once you have looked up a binding in a module, you can be sure that it
> > remains valid and that all lookups with the same symbol in a module
> > will return the same binding.  When you need to make changes to a
> > module that are not allowed by these rules, you must abandon the old
> > module and create a new one.  Modules that use the old module in some
> > way need to be reconstructed as well, and so on.  See @pref{FIXME} for
> > more information about this.
> 
> Hmmm.  This needs to be clarified, especially with respect to memoized
> code.

Yes, this is actually the big point.

> > When Guile executes or compiles some code, it does this always in the
> > context of a module.  That module is called the @dfn{current module}.
> > Set settable procedure @code{current-module} can be used to access the
> > current module.  The global identifiers of the executed or compiled
> > code are looked up by finding the object that is bound to the
> > identifier symbol in the current module.  In certain contexts, the
> > object must be a variable so that it can be referenced or set, in
> > others, it is also allowed to be a macro transformer which is then used
> > to expand the evaluated form.
> 
> I think this paragraph is incorrect:  Only when guile executes some
> top-level expressions the lookups are done in the current module.

Yes, exactly.  I was only thinking about top-level forms, but haven't
said so explicitely.

> > To access bindings from another module, the desired bindings are
> > simply copied into the accessing module.  There are several ways to
> > select which bindings to copy exactly and how to transform the symbols
> > on the way.  Ultimately, however, imported bindings are added just
> > like local bindings.
> 
> That means, modifying a value at the location of a binding will also
> modify the value for the source module.

Ahh, good point.  I don't think we want to allow this.  That is,
'define' will only reuse local bindings and will complain about
existing imported bindings.  I had hoped that the distinction between
local and imported bindings doesn't need to be made...

> Ahh.  Conflicting imports will result in errors.  But:  What happens if an
> imported binding is overwritten by 'define' in the current module?
> According to R5RS, in such a case 'define' becomes 'set!'.  And this would
> influence the source module of the definition.  Hmmm.

Yes, no good.

> Can one use the same module several times, every time specifying
> some different SELECTION and RENAMER?  Can the same variable be
> imported several times under different names?

Yes, that is the intention, but I haven't thought about the consequences.

Thanks for your comments!

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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

Re: What replaces scm_register_module_xxx (Doc update?)

[Dirk Herrmann]

On 17 Aug 2002, Neil Jerram wrote:

> >>>>> "Dirk" == Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:
> 
>     Dirk> On 12 Aug 2002, Marius Vollmer wrote:
> 
>     >> A Guile module is a data structure with the features described in the
>     >> following sections.  You can work directly with the data structure in
>     >> your programs, but normally you refer to them indirectly via the
>     >> familiar hierachical names like @code{(ice-9 popen)}.
> 
>     Dirk> I think it would be helpfull to explain that there is no relationship
>     Dirk> between modules named (a b) and (a b c).  People might assume that there
>     Dirk> is some subset/superset relationship.  Especially since I remember that
>     Dirk> once there was such a concept in guile.
> 
> There still is.  In this case, and assuming that both modules have
> been loaded, there is a variable named `c' in (a b) whose value is the
> module (a b c).

Is this just historical cruft?

Best regards,
Dirk



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

Re: What replaces scm_register_module_xxx (Doc update?)

[Neil Jerram]

>>>>> "Dirk" == Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

    >> There still is.  In this case, and assuming that both modules have
    >> been loaded, there is a variable named `c' in (a b) whose value is the
    >> module (a b c).

    Dirk> Is this just historical cruft?

AFAIK, it's a corollary of the current module implementation that
would be ugly to try to hide.

But I don't believe it's documented as a feature anywhere, and I think
it should be possible for a new implementation of Guile's module
system to avoid this property.

Marius can probably be a lot more precise ...

        Neil



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

Re: What replaces scm_register_module_xxx (Doc update?)

[Marius Vollmer]

Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

> > There still is.  In this case, and assuming that both modules have
> > been loaded, there is a variable named `c' in (a b) whose value is the
> > module (a b c).
> 
> Is this just historical cruft?

I would say so.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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