[R6RS] Core vs. library
William D Clinger
will at ccs.neu.edu
Wed Mar 15 08:05:52 EST 2006
My opinions on Anton's questions...
> 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.
That terminology makes it nearly impossible to talk about
derived syntax that belongs in the core, not a library.
What really matters are:
* What things are available through "scheme://r6rs"?
* How are things that aren't available through "scheme://r6rs"
divided up into libraries?
* What other distinctions might improve the presentation
of the R6RS document?
> 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.
Once again, this is an unfortunate choice of terminology.
With your definitions of "library syntax" and "built-in
syntax", I would argue that "let" should be both. That's
> 1. Should "core" mean, essentially, "built-in primitive"?
No. I think "core" should have no connection to the split
between "scheme://r6rs" and the libraries, but should have
meaning for the presentation of the R6RS. I think "core"
should denote the set of all syntax and procedures, whether
in "scheme://r6rs" or libraries, that the editor of the
R6RS chooses to use as a primitive basis for describing the
> Or should it mean something broader?
Neither broader nor narrower, but different.
> More generally, what is the relationship, if
> any, between "primitive" and "core"?
"Core" should mean "primitive", but should not imply
> ....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?
> 3. If a feature is classified as "library", does that mean it has to
> actually be defined in an R6RS library?
Since you are using "library" to include all derived syntax,
I have to say the answer is no. I think that is terribly
confusing, however. I would prefer we use the word "library"
only when referring to libraries.
> 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?
I would suggest that the R6RS be divided into a core report
that describes the syntax and procedures taken as primitive,
a base report that describes what is implied by "scheme://r6rs",
including those things that have already been described by the
core report, and a library report that describes things that
are not in "scheme://r6rs" but are in one of the standard
libraries, including those things that have already been
described by the core report.
More information about the R6RS