Background

SLIB is a portable scheme library meant to provide compatibiliy and utility functions for all R4RS scheme implementations. Since 1991, more than sixty contributors have grown SLIB's source and documentation to over one megabyte. Experience with a large corpus of shared code should make clear the goals and constraints a module system should have. From my experience with SLIB I conclude that a code library should:

1. Contain portable code for useful procedures;
2. Organize into logical groups (modules) those procedures likely to be used together;
3. Allow coders to specify modules using mnemonic names which are independent of, and unaffected by, the conventions and constraints of file and operating systems;
4. Document each module and its procedures;
5. Allow modules to be used in any combination which makes sense;
6. Have small runtime resource overhead;
7. Consume runtime resources only for those modules in use;
8. Not replicate sharable modules in multi-user implementations;

Goal 3 is to create an abstraction barrier between module (feature) names and library internal details. This seems a natural goal; Yet, the C-library does not satisfy goal 3. Almost all of the discussion of module systems for Scheme has also not addressed this issue. Since there has been little controversy over SLIB's feature-to-file translation (and no interest in standardizing SLIB), I will take as given that:

• There is some (invisible to me) natural distinction between module systems and libraries;
• RRRS-authors feel that modules are in the purview of the report, but libraries like SLIB aren't.

Most of the module discussions deal with properties which are nice, but not strictly necessary for library operation:

1. In order to fully utilize a library, compilers for the language should resolve module references at compile time.
2. Module code and data built by module code should be safe from mutation except by module procedures. One way to protect module data is to export only procedures and macros. The opacity of procedures allows module procedures to control access to data.
3. Only documented procedures and syntax should be accessible to module users.
4. Modules should be a first class datatype.
5. The module system should work with existing code.

Go to the first, previous, next, last section, table of contents.