[R6RS] modules?

Matthew Flatt mflatt
Mon Apr 12 21:51:02 EDT 2004

At Mon, 12 Apr 2004 17:34:10 -0400, Marc Feeley wrote:
> My main issue with Matthew's proposal is that I don't understand how
> the pieces of code (the modules) are put together to form a program.

I'm not sure what you mean. Suppose that I have two modules...

 File a.ss:
  (module a r6rs
    (define x 12)
    (provide x))

 File b.ss:
  (module b r6rs
    (require "a.ss")
    (define (f y) (+ y x))
    (provide f))

When you give "b.ss" to a tool (such as an executable generator),
that's all it needs. The reference to "a.ss" lets the tool find the
second module.

> 1) standalone statically linked program (we know all of the
>    constituent modules at application build time)

Covered above.

> 2) dynamically linked program (we know some of the modules at
>    application build time and some others will be loaded at run time,
>    possibly more than once for debugging or hot code-upgrade reasons)

Debugging and sounds like a tool issue, rather than a language issue.

Probably the module standard should support a way to dynamiclly load a
module and obtain values for its exports. That would allow hot code
upgrade (probably implemented through some nice abstractions provided
by a library module). For this purpose, MzScheme provides
`dynamic-require'; as the name suggests, it's a dynamic version of
`require' that takes a quoted module path, plus a symbol for an
export's name.

For shared libraries, the `lib' module-path form refers to library
modules that are installed in a standard place (much like .so libraries
are found in standard places). An executable generator might refrain
from static-linking certain libraries.

> 3) scripts (there is a single file containing the whole user program,
>    but some code may be in standard libraries, or libraries installed
>    by the user/administrator in some standard location)

MzScheme's `module' is certainly compatible with something like
SRFI-22 (revised so that the script file contains a module that exports

> 4) REPL-style "program" where the user manually constructs the program
>    by entering code, loading files, and requesting evaluations.

I think this is a tool issue, and doesn't belong in a module standard.

FWIW, MzScheme provides a typical Scheme REPL, and the REPL accepts
`module' and `require' declarations. In that case, a `module' is
required just using it's symbolic name.

  > (module a mzscheme
     (define x 12)
     (provide x))
  > (module b mzscheme
     (require a)
     (define (f y) (+ y x))
     (provide f))
  > (require b)
  > (f 10)

MzScheme also implements each module as a separate top-level
environment, and allows switching among modules in the REPL (like
Scheme48 and other systems). This arrangement works well for MzScheme,
but probably wouldn't make sense for all Schemes.


More information about the R6RS mailing list