[R6RS] Library syntax versioning
Anton van Straaten
anton at appsolutions.com
Tue Apr 25 20:49:44 EDT 2006
> 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"
(display "Hello World")
I propose an obvious alternative to this, which is to simply omit any
library syntax version specifier, e.g.:
(display "Hello World")
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).
More information about the R6RS