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] |
>@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? :)