[R6RS] Core vs. library
Anton van Straaten
anton at appsolutions.com
Wed Mar 15 00:46:06 EST 2006
This message provides a brief survey of the R5RS perspective on
primitive vs. library features, and poses four questions for how the
core vs. library and related distinctions should be made in R6RS.
R5RS divides syntax and procedures into primitive and library (or
"derived" in the case of syntax). In this message, I'll use the term
"library" to apply to both library procedures and derived syntax.
In general, if an R5RS feature can "easily" be implemented in terms of
primitive features, then it is classified as library; otherwise it is
primitive. One somewhat anomalous case is quasiquote, which because its
"macro definition is complex" (i.e. not easy), is classified as primitive.
R5RS also defines "built-in" or "standard" procedures, which include
both primitive and library procedures. In R6RS, these would presumably
correspond to the procedures available when the "scheme://r6rs" language
is specified in a module. I'll call these features "built-in" in this
message, referring to both procedures and syntax.
Just for reference, the R5RS derived expression types include let, let*,
letrec, begin, do, named let, cond, case, and, or. Some R5RS built-in
library procedures include boolean?, equal?, zero?, abs, max, min.
Some questions related to how these issues should be treated in R6RS
follow. There are some quite basic issues here, which we should make
sure we're agreed on.
1. Should "core" mean, essentially, "built-in primitive"? Or should it
mean something broader? More generally, what is the relationship, if
any, between "primitive" and "core"?
As an example of an alternative approach, in The Definition of Standard
ML, there's a "Bare" language which corresponds roughly to the R5RS
primitives; and a "Core" language which includes derived forms, such as
"case", "if", "while", "orelse", and "andalso". Also, the Definition of
SML defines these derived forms in an appendix, but the R6RS probably
can't get away with this, since more critical forms such as LET are derived.
A related issue is that in actual implementations, user libraries might
define the equivalent of primitives - e.g. via an FFI - which would
presumably not be considered "core", except possibly with respect to the
library in question. Also, some R6RS libraries which are not "built-in"
may define primitives - an example might be the symbol-hash procedure,
in a hash functions library, which may not be built in. This could be
called a "primitive library procedure"; should such a procedure also be
classified as "core"?
2. If a feature can be defined in terms of primitive features, does that
always imply that it is a library feature? I.e. does "derivable" always
imply "library"? As a possible counter-example to this idea, in R5RS,
quasiquote is listed under "Derived expression types", as primitive syntax.
3. If a feature is classified as "library", does that mean it has to
actually be defined in an R6RS library? So for example, if LET is
classified as a library feature, then it might be in e.g a "base-syntax"
library, which would be one of the built-in libraries present in the
4. A question which Mike is interested in: how will the Report be
divided up? Will the entire core be in its own section(s), or will it
follow the R5RS model in which the definition of built-in library
features are interleaved with core features? (The latter question is
moot if built-in library features are considered part of the core.)
More information about the R6RS