[R6RS] Splitting into core and libraries

Michael Sperber sperber
Wed Jul 20 15:34:31 EDT 2005

Matthew Flatt <mflatt at cs.utah.edu> writes:

> More concretely, I suggest pretending for now that the standard will
> define a single module called "r6rs", and that all implementations must
> provide it. This module contains everything that we think is necessary
> for portable, useful Scheme code.
> Some will complain that this language is too big, and they will be
> right. Time permitting, then, we should go back an partition "r6rs"
> into smaller modules, and define variants of the smaller modules. For
> example, "r6rs" might include `char-upcase' that must work on all of
> Unicode, but a different module would offer `latin-1-char-upcase',
> whose domain and range is the Latin-1 subset of Unicode.
> This strategy runs the risk that we'll waste time on questions about
> "r6rs" that would go away if we went straight toward defining a
> collection of modules. I'm more comfortable with this risk, though,
> than the risk of setting up too large a task by defining many modules
> up front.

I have no problem with this strategy, but I don't want us to trade
deadline time for incomplete partitioning, for two reasons: it's hard
to reverse, and it has significant implications.

First off, it may not be possible to put everything we do for R6RS
into a single namespace---R5RS compatibility libraries for things like
arithmetic and I/O come to mind.

Also, the design library system may make the implications of having a
big "core" more or less serious.  Example:

MzScheme's "mzscheme" language is something like a "useful core" or
probably more like a "big core" (correct me if I'm wrong).  Now, the
MzScheme module language is good at dealing with name conflicts
between different imports, but it's terrible at dealing with name
conflicts between the base language and imports.  I'm banging my head
against this *all the time* when programming with MzScheme:

> (module m mzscheme (require (lib "19.ss" "srfi")))
stdin::129: module: identifier already imported (from a different source) at: make-date in: (require (lib "19.ss" "srfi"))

In MzScheme, I actually have to create some artificial subset of
mzscheme as a separate, named module (in MzScheme's case, in a
separate file) to accommodate the situation.

Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla

More information about the R6RS mailing list