[R6RS] library syntax

[Matthew Flatt]

At Sat, 08 Jul 2006 12:51:34 -0400, dyb at cs.indiana.edu wrote:
> >   <import-spec> --> <import-set> | (for <import-set> <import-phase>*)
> >
> >   <import-phase> --> run | expand  ; possibley eval as well
> 
> I forgot to mention earlier that Matthew and I decided that, when
> <import-spec> --> <import-set>, i.e., in the absense of an explicit
> (for --- <import-phase>*) declaration, the default set of phases
> should be run and expand.

I did agree at the time, but I'm not so sure now.

As I understand it, the argument in favor of defaulting to for-expand
is that it makes macro writing easier. In particular, simply requiring
`r6rs' would introduce appropriate bindings for macro definitions,
instead of forcing programmers to write an explicit for-expand require
to enable macro definitions.


The problem with implicitly requiring for expand is that the imported
module might require run-time support that isn't available at compile
time. (As always, please substitute "expand" for "compile" as
necessary.)

For example, you might want to compile a program using a GUI library
that needs an X server at run time, but you want to compile without an
X server. The GUI library would most naturally connect to the X server
as part of its initialization, but that won't work if the GUI library
is required for expand (perhaps transitively through eight other
library layers built on the GUI).

Of course, the GUI library could connect to the X server lazily, so
that using the library at expand time will work (as long as no window
is created). But implementing the lazy connection is likely a pain; in
any case, I don't think the module system should force the GUI-library
implementor into that position.

Besides GUIs, I could imagine a database library where the database
isn't running at time time, or platform-specific libraries compiled on
a platform different from the run-time platform.


Going back to the original goal, maybe it should be addressed on the
provide side instead of the require side. For example, an `r5rs'
library might specify that importers get run-time bindings like `cons'
and `car, plus a expand-time binding `syntax-rules'.

[JFYI, MzScheme does this indirectly, and in a way that only works for
the language position. The R5RS language module, for example, exports a
macro that controls the top-level expansion of importing modules; this
macro injects a require-for-syntax of `syntax-rules' into the beginning
of the importing module's body. Similarly, the module-body macro from
the `mzscheme' module injects a require-for-syntax of itself.]

Matthew