Re: module naming

[thi]

   From: Rob Browning <address@hidden>
   Date: 24 Apr 2001 00:28:10 -0500

   (If this topic has already been beaten to death in the past, and I'm
    just re-starting one of those inevitable cyclical arguments, then
    please let me know and I'll shut up :>)

well, i'm participating in the rehash so i can't very well fault anyone
for doing the same (haven't written that refbot yet)...

   So what does "@" do?

if you have `foo' defined in (my module), but not exported, you can
access it like:

(((@ my module) 'foo) 42)

this is likely to give compilation-oriented folks a heart attack,
though.  i wrote `@' when first coming to grips w/ the module system,
which despite all this Waiting for a Replacement, has grown on me (in a
way, like a fungus :-).  however, having said that, my code never uses
`@' -- it's a piece of mighty slack best left in the jar and studied
from afar, included in the tar but never in the car (actually, i do use
it in some test harnesses, the original application)...

   However, I wonder if, going under the principle of "least necessary",
   we could modify use-modules to accept an argument like
   :no-default-imports so you could say:

     (use-modules (foo bar) :no-default-imports)

   and then have a parallel operation to "export" like this:

     (import-from module module . items)

   [example snipped]

   Note that we could do without the :no-default-imports option to
   use-modules and just let people use import-from *instead of* ever
   having a use-modules in these situations, but that brings up some
   "interesting" and possibly confusing questions, about if/when code at
   the top level of a module file should actually run (though I feel
   fairly sure that's probably been discussed as a thorny issue on the
   compilation front too).

i would hope that the if/when-to-run-code issue is separate from the
visibility issue.  hmmm.

   One other thing I can see might also be helpful would be to have the
   ability to use a module, but rename all its symbols in a programmatic
   way on import, something like this:

   [example snipped]

actually, this is what i would advocate as the best interface possible
because it completely specifies module dependency and bindings selection
and yet maintains backward compatibility to a no-granularity form.  to
combine the import and renaming examples:

     (use-modules (foo bar)
      :select (x y (a new-a) (b new-b) z)
      :rename (lambda (sym) (symbol-append 'foo: sym)))

we would need to specify that selection occurs before renaming.  if the
select-clause is omitted, the default would be to use the entire exports
list.  this way, degenerate `(use-modules (foo bar))' works as before.

   But it feels like there ought to be a more elegant way to solve this
   problem without a more complex interface.  Maybe something like the
   following (given a public way to ask a module for its exports):

     (apply
      import-from
      (map
       (lambda (sym)
         (list sym
               (string->symbol (string-append "foo:" (symbol->string sym)))))
       (module-exports (foo bar))))

   though of course, the scoping for this probably wouldn't be right and
   apply doesn't work on macros :>

this is interesting but luckily accessing the entire exports list is
currently the default behavior so our changes need be only additive.  a
related issue is how to make whatever interface we finalize on available
to `define-module'.

thi