[R6RS] Core vs. library

[William D Clinger]

Anton wrote:
> > 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.

Regardless of the mechanism, there should be some easy way
to write programs that import everything defined in the R6RS
document(s), including libraries for such things as hash tables,
fixnum operations, flonum operations, and delay/force.

There should also be some easy way to write programs that
import only a smaller language that excludes some of the more
specialized or controversial features such as:

* do
* named let
* delay and force
* fixnum operations (fx+ etc)
* flonum operations (fl+ etc)
* set-car!, set-cdr!, and other destructive operations on lists
* values, call-with-values, let-values, etc
* load, eval, scheme-report-environment, null-environment
* R5RS i/o (assuming it remains part of the R6RS at all)
* records
* syntax-case
* hash tables
* case-lambda, cond-expand (if in the R6RS at all)
* bitwise operations on exact integers (if in R6RS)
* homogeneous numeric vectors (if in R6RS)
* support for regular expressions (if in R6RS)
* support for system operations (if in R6RS)
* formatted output (if in R6RS)
* weak pointers (if in R6RS)
* void object (if in R6RS)
* gensyms and uids (if in R6RS)
* R5RS compatibility library (if in R6RS)
* Unicode normalization (if in R6RS)

For many of the above, the rationale for being able to leave
them out is that the R6RS spec will be in conflict with code
that uses implementation-specific extensions to R5RS, and it
would be a nightmare to port code to the R6RS if you had to
deal with all of those changes at once.  We need to make it
easy for programmers to convert just one subsystem at a time.

As I understand it, SRFI 83 currently provides no way for a
programmer to exclude items that are implicitly imported by
"scheme://r6rs".  Until that is changed, I must object to
having "scheme://r6rs" include the features listed above.
If that is changed, however, then I will no longer object to
making "scheme://r6rs" include all of those features.

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

I don't have any problem with LET being in a library that is
included as part of the "scheme://r6rs" language.  If there
is no way to import or to create subsets of "scheme://r6rs",
however, then I can't see any observable difference between
LET being in a library and LET not being in a library.

Will