Re: Module Considerations

[Mikael Djurfeldt <mdj@nada.kth.se>]

Jim Blandy <jimb@red-bean.com> writes:

> @item
> Guile should allow modules to be written in different languages, and
> then translated to Scheme for interpretation (the @dfn{translator}
> idea).  For example, it would be nice to support Emacs Lisp, or provide
> a language with C-like infix syntax and Scheme's semantics.

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

Currently, there are at least two different kinds of uses of syntax
translation in Guile: 1. translating a foreign syntax into Scheme
(ctax); 2. customizable macro expansion (syntax-case).  Probably there
are other kinds as well.

These are orthogonal so that you can imagine that you write a syntax
translator which translates code into a scheme variant which uses some
new macro system.  In such a case, the module needs to do two
translation steps:

foreign syntax --> scheme --> macro expanded scheme

The solution could simply be to allow for a list of translations in
the module specification.

> @item
> As a special case of the above, Guile should support variant syntaxes
> for Scheme itself --- SCSH's case-sensitive scripts, R4RS, R5RS, DSSSL,
> and so on.

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.


Also, I'd like to add the following items:

@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.

/mdj