This is the mail archive of the guile@sourceware.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: New module system wishlist



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

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