Re: Module Considerations

[Jim Blandy <jimb@red-bean.com>]

>It may even be necessary to support a chain of translations.

The reader should be specified by a Scheme expression which must
evaluate to a function.  That would make it easy to specify a chain of
readers --- just say:

  (define-module tarantula (export banana bunch)
    (reader (lambda args (macro-expand (apply tarantula-read args))))
    (file (bugs tarantula)))

(This is something like SCSH's syntax.)

>There seems to be a need for a module to specify various syntax
>options (case-sensitivity, keywords).  Probably, we should generalize
>this so that we get a generic mechanism for specifying syntax options
>for module code.

Yeah:

  (define-module mod (export a b c)
    (reader (R4RS 'prefix-keywords))
    (file (subdir file)))

>@item
>There should be a way of organizing modules hierarchically so that not
>all modules crowd on the same level.  A package writer may want to
>divide his code into modules although some of the modules have no
>meaning outside the package.  It is then silly to publish them outside
>the package.
>
>@item
>There should be a way to refer to sibling modules (on the same level
>in the module hierarchy) without using the name of the "parent"
>module.

I've added these to the wish list.  I see their value, by analogy with
variable names.  But if modules have hierarchical names, doesn't that
address a good deal of the problem?  Suppose I've got a module that's
a GDBM interface.  I've got a module that's a shared library of C glue
code called (db gdbm glue), which is used by a module of Scheme code
called (db gdbm table) which I actually intend people to import.
Unlike variables, there's little danger of (db gdbm glue) conflicting
with anything else, and anyone who imports (db gdbm glue) deserves
what they get.