[R6RS] Core vs. library

[Anton van Straaten]

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 
"scheme://r6rs" language.

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.)

Anton