R. Kent Dybvig
Wed Nov 10 16:02:40 EST 2004
Manuel and Mike have suggested some fundamental changes to my module
proposal that destroy much of what I think is good about what Matthew
and I came up with through our discussions and compromises. I've tried
without success to reconcile these changes with how I think the module
system should work.
Here are some points I feel strongly about where there appears to be too
much disagreement for compromise. If someone sees room for compromise
on these points, please let us all know.
- Implicit export declarations should always be required, for reasons
I've already stated.
- Local require forms should be permitted, for reasons I've already
- We should be able to write macros that expand into require, provide,
and even module forms. The opening paragraph of the r5rs expresses
the guiding principle here:
Programming languages should be designed not by piling feature on top
of feature, but by removing the weaknesses and restrictions that make
additional features appear necessary. Scheme demonstrates that a very
small number of rules for forming expressions, with no restrictions
on how they are composed, suffice to form a practical and efficient
programming language that is flexible enough to support most of the
major programming paradigms in use today.
Note specifically the part about "no restrictions on how they are
composed". I realize I may be the only one, but I truly dislike having
any reserved words or un-abstractable meta language.
(I'm not necessarily opposed to a convention for shared libraries stored
in some standard "CSAN" repository that, say, requires the top-level
forms of a library file to be module forms, but such restrictions
should not apply to Scheme programs in general.)
- While I don't mind including support for separate interfaces, they
should not be required.
- While I don't mind including support for type declarations, they
should not be required.
- There should be a standard way for a require forms to specify where to
look for implementations of the required modules. A portable Scheme
source file (e.g., shell script) should be just as easy to write as,
say, a Perl script, and should not require any external configuration
file to tell the implementation where to find required modules.
In particular, there should be a way to specify pathnames that are
relative to the current directory and pathnames that are relative to
some installation-specific set of library directories.
We may be able to resolve, in a sense, some of our disagreements by
giving some things the "it is an error" label, as Matthew has suggested,
and leaving other details implementation dependent, but this will not
give us truly portable libraries.
Here are some questions I have for others, regarding claims or preferences
that I don't understand.
* Why are any changes to my proposal necessary to allow the use of
Unix "Make"? In particular, having a separate specification language
is not necessary, and being able to determine requirements without
expansion is not necessary, or Make could not be used for C.
Incidentally, I too prefer to use Make and have used it extensively
for over 20 years.
* If actual requirements are specified via some external configuration
language, why do we need a require form at all? If it's just to
specify the particular set of identifiers that need to be made
visible from a required module, why is there any resistance to allowing
abstraction of require forms and/or require forms to appear in local
* For those who favor separate configuration information, what do you
anticipate a Scheme shell script that requires one or more portable
modules will look like? Will all scripts have to have separate
configuration and/or Make files?
* For those who want require and provide forms to be hard-wired so that
they can be processed by external tools, would you extend this argument
also to the definitions appearing with the body of the module? If not,
why not? If there is useful information to be gleaned from the require
and provide forms, there is surely even more useful information to be
gleaned from the actual definitions.
More information about the R6RS