[R6RS] Core vs. library

[Anton van Straaten]

Will, I have one question about your position which I think you may have 
implicitly answered, but I'd like to confirm:

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

An additional point is whether "scheme://r6rs" should be defined to 
include any libraries.  This allows for the the possibility of libraries 
which depend on a subset of "scheme://r6rs", even if the exact mechanism 
for doing so is left to implementations.

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

While I agree on the point that not everything derived should 
necessarily be called "library", or be in a library, the idea that 
something could be both library syntax and built-in relates to my point 
above.  I gave an example in my original post of derived syntax such as 
LET being in a library which is included as part of the "scheme://r6rs" 
language.

My impression is that you're not allowing for this possibility, is that 
correct?

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

I generally agree with this, and the other points you made, subject to 
some discussion of the point I've raised above.

Anton