subverting use-modules restriction + module system RFD

[thi]

in guile 1.5.x and later, `use-modules' is permitted only at top-level.
suppose you're writing some kind of shell that only loads modules on
demand, in which case a non top-level (e.g., conditional, programmatic)
"use-modules" is desirable.  you can try this:

(define (runtime-use-modules name)
  (process-use-modules
    (list (list name))))

simple example:

(case (string->symbol (cadr (command-line)))
  ((state-summary)
   (runtime-use-modules '(ttn rcsutils))
   (for-each display-rcs-state-summary (cddr (command-line))))
  (else
   (error "command not found")))

NOTE!  this is probably an approach that you cannot rely on to be
available for all time.  although the module system user interface seems
to be relatively stable, the programming interface is still in flux...
also, such shenanigans might very well be frowned upon by some.

personally, i plan to use (and provide via ttn-pers-scheme) this
`runtime-use-modules' abstraction, updating its implementation as the
need arises, until `process-use-modules' or an equivalent is officially
deemed part of the module system programming interface.

in fact, putting on a guile maintainer hat, i would love to foster
discussion on guile-user re module system user- as well as programmer-
interfaces.  especially, fresh perspectives w/ grounding in Real Code
are welcome (see guile-devel archives for lots of theory!).  questions i
have for other guile users include, but are not limited to:

 - what is a "module"?
 - what is the trust model among/between modules?
 - is a single exports list enough?
 - how does the module system interact w/ goops?  smobs?  extensions?
 - is bindings selection and renaming sufficient for interface design?
 - is "exporting" a barrier, a suggestion, something in-between?
 - what is the "shape" of the modules in your app?

(etc.)  just so you know, my bias is towards validating the current
design since it has some pet features i'm fond of.  however, the bias is
not so strong as to drown out the apprecaiation for critical feedback.
(i'm also hoping to snarf some of the discussion into the guile manual,
hehe. ;-)

thi