[R6RS] modules?

[Matthew Flatt]

[Sorry it took so long to respond...]

At Sun, 02 May 2004 17:49:54 +0200, Michael Sperber wrote:
> A while ago, I commented on "interfaces as nameable entitities" and
> "more than one module per file."  Do you have any take on that?

With multiple modules in one file, you need a way to refer to each
particular module within a file. But filesystems already do a perfectly
good job of handling hierarchy, so I favor multiple files within a
directory, instead of multiple modules within a file.

It's not a big issue to me. For MzScheme, we originally imposed the
one-module-per-file constraint with the expectation that we'd try
multiple modules later. But it's never seemed worth the trouble, and
it's a rare request. (In contrast, putting helper functions for macros
in the same module as the macro---as supported by Chez's `meta'---is a
popular request.)

> Generally, the issue of parametricity still worries me.  Being able to
> link a program against several different libraries with the same
> interface is pretty important to me.  Arguably, it shouldn't be done
> in the top-level module system you propose.  On the other hand, I'm
> pretty unhappy with the place this takes in MzScheme, where you can
> build a "unit" within a module, and instantiate and exports all of its
> exports to get a module.  This has two disadvantages:
> 
> - Being able to link against another library with the same interface
>   requires changing the library.
> 
> - Changing the library may not be possible if it's from some
>   third-party vendor.

I think both of these bullets have to do with the fact that PLT
programmers no longer use `unit', because linking units together is too
much work. I think I know how to make unit linking less work, but I
haven't gotten around to re-writing the `unit' forms.

> Again---I'm not sure this should be addressed in the top-level module
> system we're discussing now, or even any module system we specify in
> R6RS. On the other hand, I'd like to avoid getting into a corner
> where it's difficult to add something later on that avoids the
> aforementioned problems.

I remain convinced that MzScheme's `module' is compatible with a
low-overhead component system, but I can't point to an implementation.

Matthew