[R6RS] modules?

[Matthew Flatt]

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
`main').

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


Matthew