[R6RS] Core vs. library

[William D Clinger]

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

> 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
entire language.

> 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
"built-in".

> ....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"?

Yes.

> 2. If a feature can be defined in terms of primitive features, does that
> always imply that it is a library feature?

No.

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

Will