This is the mail archive of the guile@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] |
>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.