[R6RS] Core/library split

William D Clinger will at ccs.neu.edu
Mon Aug 14 13:27:09 EDT 2006

Mike wrote:
> First off, I'm increasingly uncomfortable with the term "core
> language" as it usually does suggest some "semantic core" as opposed
> to something "minimally useful," which is what we've been doing....
> I suggest the term "base language" or "base library"
> for what we're doing.

I too favor this terminology.

> ....The concept of
> lumping everything R6RS into a "r6rs-big" library seems OK, but would
> not be useful to me personally.

Yes, but you are an unusual programmer.

There is a portability argument for r6rs-big.  Regardless
of what we do, most R6RS-conforming implementations are
likely to provide a library that includes everything in
R6RS together with extensions (and possibly substitutions)
provided by that implementation.  If there were no r6rs-big,
then programmers that don't actually need to use any
implementation-specific extensions would import some
implementation-specific library anyway, just because it
would be the most convenient way to get everything that's
described by R6RS.  That would create gratuitous

> Two issues are immediately apparent:
> - I've added syntax-rules, as define-syntax & friends have zero
>   usefulness without them.  (Debatable; I could live with syntax-rules
>   being in a separate library.)

I favor having syntax-rules in the base library, but it
was already in r6rs-small, according to the latest draft
of draft/corelib/core-library.txt.

One oddity about that latest draft is that the generic
arithmetic procedures are said to be part of r6rs-core,
and therefore part of r6rs-small and r6rs, but are
explicitly mentioned as a separate library that is
one of the differences listed between r6rs-small and
r6rs.  Something is wrong here.

> - I've moved dynamic-wind and call/cc to a separate library.  This
>   seems congruent with moving out but not deprecating
>   set-car!/set-cdr!.  (Also no big deal for me personally.)

In my opinion, leaving a procedure out of r6rs-big
(or whatever we call it) will be an effective way to
deprecate it, even without using the d-word.  I favor
leaving dynamic-wind and call/cc in r6rs-big, but not
set-car! and set-cdr!.

To give you all some idea of the conglomerated libraries
I'd like to see, I'd propose something the following two:

    that would include:
    the r6rs-core stuff of draft/corelib/core-library.txt,
            do, named let
            set-car!, set-cdr!
            values, call-with-values, let-values, letrec-values
            call/cc, dynamic-wind
            exceptions and conditions
    generic arithmetic
        (this is already part of r6rs-core, but I'm listing
        it explicitly because of the oddity mentioned above)
    error, violation, contract-violation
        (BTW, I don't care for the name of contract-violation)
    syntax-rules, but not syntax-case
        (but I would probably want to exclude some of the
        hairier parts)
        (procedural and explicit-naming only)

    that would include everything described in the R6RS
    (including R5RS-compatible newline and write-char)
    except for:
        set-car!, set-cdr!
        inexact->exact, exact->inexact
        null-environment, scheme-report-environment
        eval and its minions
        quotient, remainder, modulo

Examining the list of procedures Mike proposed for r6rs-base,
I would exclude:
    (call-with-values procedure)
    (condition procedure)
    (condition-has-type? procedure)
    (condition-ref procedure)
    (condition-type? procedure)
    (condition? procedure)
    (contract-violation procedure) ; if it needs conditions
    (define-condition-type procedure)
    (do syntax)
    (eq? procedure)
    (guard procedure)
    (let syntax) ; ordinary let would be included, named let excluded
    (let*-values syntax)
    (let-values syntax)
    (letrec-values syntax)
    (raise procedure) ; if it needs conditions
    (raise-continuable procedure) ; if it needs conditions
    (values procedure)
    (violation procedure) ; if it needs conditions


More information about the R6RS mailing list