[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
non-portability.
> 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:
r6rs-base
that would include:
the r6rs-core stuff of draft/corelib/core-library.txt,
excluding:
do, named let
eq?
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
bytes
port-i/o
(but I would probably want to exclude some of the
hairier parts)
records
(procedural and explicit-naming only)
r6rs
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
Will
More information about the R6RS
mailing list