New module system wishlist

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Since we hopefully very soon will have Jost's environments integrated
into Guile, it will fairly soon (= months :) be time to implement the
new module system.

We have made at least two serious starting attempts at specifications,
but neither of these went all the way to a final spec.

In preparation for a third, and final, spec (which probably won't be
written by me), I'd like to take the initiative to some preliminary
data gathering: I'd like people to send in wishes about what features
they want to see in the new module system.

Just now I'm pretty busy (you can recognize this thusly: when I'm
busy, I don't have time to post to the list, so I do just that :),
so I'll integrate your answers into a list first after a week or so.

The list, together with earlier discussions and material, will then be
used as a basis for writing the new spec, which will of course not
propose all features.  However, this kind of wishlist may serve as a
reminder to the eventual designers of the system.

Here are a few of my wishes:

* support separate compilation

* hierarchical module names

* support relative references within the module name space (so that a
  module within a package can use a sibling module without knowing the
  prefix of the module name)

* support re-use of code (the same implementation can be presented to
  the world through several interfaces)

* support individual and group renaming of bindings when using other
  modules

* easy to import and re-export entire interfaces (so that a main
  interface in a package can function as a "relay" and publish
  bindings from many modules in the package)

* support both variable and syntactic bindings (these should be
  clearly separated, though) and mesh well with hygienic macro
  systems

* hygienic implies that we shouldn't need to care to export bindings
  which an exported macro introduces at the point of its use

* autoloading

* unmemoization protocol

* cleanliness:

  A module should be able to be totally clean.  There should be no
  need to have *any* extra bindings in a module (a la
  %module-interface or `define-module').

  Therefore, we should have at least one dedicated "command" or
  "config" or "repl" module.

  It would probably be a good idea to follow other good Scheme
  interpreters' lead and introduce the ,<command> syntax for walking
  around modules, inspecting things, entering the debugger, etc.
  Such commands can be looked up in this repl module.

  If we insist on not using ,<command> syntax, we are forced to let
  the module use list consist of a "sticky" part and the rest, where
  the "sticky" part is only available at the repl prompt and not to
  the code within the module, and which follows us when we walk around
  in the system.

* well integrated with the translator framework

  We should be able to say that a module uses a different syntax or
  language.

* Note here the nice config language of the Scheme48 module system
  where it is possible to separate code from module specification: the
  module specification can use scheme syntax and rest in one file,
  while the module itself can use the syntax of another language.

  This config language also supports re-use of code in a neat way.

* examine connection with object system: how easy is it to support
  Java and other class-centered object systems?


Please fill in with more points!  It is OK to provide mutually
inconsistent points.  The design decisions (and a possible discussion)
will be taken later.