This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Module Considerations



>@item
>Should be able to wrap one or more existing source files containing
>various definitions as module without modifying any of the souce files.
>(Can be handled with some kind of "include" mechanism.)

Added.  Scheme 48's module system certainly allows this.  I think
something like this would be useful for cleanly enclosing slib in
Guile's module system.

>@item
>The module control language should be Scheme.  A module definition
>should be mixable with other module definitions and regular
>Scheme definitions in a single source file.

This is an interesting case.  Certainly, module definitions should
have an open-ended syntax.  However, I think it's really helpful for
them to have a declarative nature, rather than an imperative one.

I am very concerned that we be able to support static linking in a
simple way.  In the common case, static linking should differ from
dynamic linking only in the way you build the executable, not in the
way the code refers to modules.  So we need to be able to produce a
list of object libraries to link against at compile-time.  One way to
do this, which appeals to me, would be to walk the load path searching
for module declaration files, and teasing out from them the names of
libraries to link against.  (Let's suppose module declarations live in
separate files from the sources, as in Scheme 48, with a distinctive
naming convention.)

So, for example:

  $ build-guile link
  -lguile-gdbm -lguile -lqt -lgdbm
  $ gcc my-guile-app.o `build-guile link` -o my-guile-app

In this example, -lguile and -lqt come from Guile itself, and
-lguile-gdbm and -lgdbm come from the module declaration file that was
installed with a gdbm interface.

In order for this to work, there has to be some regularity in the
syntax for declaring modules, so one can parse them without actually
loading every module on the system.

Perhaps it would be enough if loading a module declaration file
promised not to actually load the module, but recorded enough
information that the module could be loaded on demand.  Then, the
on-demand information would be enough to construct the link list.

>@item
>Must be able to create a module from existing modules.

I'm not sure I understand this.  Do you mean that one should be able
to produce a single module that exports names imported from many other
modules?

>@item
>A module (a source-code construct) maps into (evaluates to, or at least
>names) a package/environment, which is a first-class Scheme object.

Yeah, there needs to be a datatype underlying all this for pulling
funky reflective tricks.  Like debugging.

>@item
>Avoid ugly non-Scheme syntax (e.g. prefix comma) for manipulating modules,
>even in top-level read-eval-print loop.

So you don't like Scheme 48's repl?  :)