[R6RS] Library syntax versioning

[Anton van Straaten]

Action item:
 > send email proposing library modifications to allow subsetting,
 > supersetting, defining new libraries, and to allow for lexical syntax
 > extensions or future changes

This message addresses the latter issue: how to allow for lexical syntax 
extensions and future changes in the library syntax.

With the proposed core/library split, a library body no longer has a 
default language.  This supports a library's use of subsets or supersets 
of the R6RS, depending on the library's requirements.

The library syntax proposed by SRFI 83 includes the specifier 
"scheme://r6rs", which with the above change serves only to specify the 
version of the library syntax being used.  This is rather heavyweight 
for what it provides.  Ideally, the library syntax version specifier 
should be more concise, if it is needed at all.

During our phone discussion of this, a number of alternative 
possibilities were suggested, up to and including the use of 
non-S-expression syntaxes for specifying libraries (at least one of 
those suggestions was a joke, at least I hope so!)  I am ignoring such 
possibilities here, for two reasons: (1) the textual representation of a 
library requires a lexically-delimited scope, which is precisely what 
S-expressions are intended for; and (2) it is desirable that libraries 
be readable with the traditional READ.

So, starting with the current proposal, combining the SRFI 83 syntax 
with the core/library proposal leads to a minimal library looking like this:

(library "hello" "scheme://r6rs"
   (import "r6rs")
   (display "Hello World")
   (newline))

I propose an obvious alternative to this, which is to simply omit any 
library syntax version specifier, e.g.:

(library "hello"
   (import "r6rs")
   (display "Hello World")
   (newline))

This doesn't explicitly allow for future changes in library syntax. 
However, future versions could provide a superset of the current syntax, 
or if that's not viable, they could provide an alternative syntax which 
can't be confused with the R6RS library syntax.

One possible drawback of this approach is that a superset of the current 
library syntax might not address the situation in which an 
R6RS-compliant Scheme attempts to load a library which uses a later 
version of the library syntax.  A library syntax which incorporates a 
version specifier would allow an implementation to cleanly reject 
"future" code, rather than dying with a possibly cryptic syntax error.

However, most languages don't provide such version specifiers: old 
compilers will simply produce syntax errors when presented with code 
written in future versions of their language.  The main practical 
requirement is typically that newer compilers are able to handle old 
code, which can for the most part be left to those newer compilers (or 
in our case, to the R7RS Editors Committee).

Anton