Thu May 20 15:36:55 EDT 2004
[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
> 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.
More information about the R6RS