This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: New module system wishlist
- To: Mikael Djurfeldt <djurfeldt at nada dot kth dot se>
- Subject: Re: New module system wishlist
- From: Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>
- Date: 20 Jan 2000 17:15:46 +0100
- Cc: guile at sourceware dot cygnus dot com
- References: <E12AixQ-00062S-00@mdj.nada.kth.se>
You said FEBRUARY =:)) ... but here's my preliminary list:
* backward compatibility
* whenever possible the module's meta-information should be stored
within the module itself (only possible for scheme files).
* the compiler stores the meta-information into a single file (FIXME:
per module, per package, directory?, per project?) and updates it
accordingly. This meta-information should still be human readable
(Sun's EJB use XML for their deployment descriptors).
* since guile is a GNU project we can expect a GNU (or Unix)
environment. That means that we should use the file system as the
module repository. (it is just that I want to avoid modules
pointing to files which are pointing to other files telling the user
"hey, that's me (the module) over there")
* every module has exactly *one* owner who is responsible for the
module *and* its interface (this contradicts with the "more than one
interface" concept).
* support module collections: "packages" with a package scope for
people working together on a project. In some sense a module is a
view on the underlying package.
* ability to request (i.e. import or access) complete packages.
* Support module "generations" (or "versions"); whenever a new module
fails to handle a request (due to an error) it will be replaced
by the old version.
* Modules should help the user to handle exceptions (note: exceptions
are not errors, see above).
* No special configuration language (like ",in" etc.). You can always
press Control-D to terminate the module's repl and return to the
config module. (hmm...)
Jost