Partial r7rs support

[ecraven]

I've started writing simple wrapper libraries for (scheme base) and the others, most functions in R7RS are either already in Chez or trivial to implement by wrapping existing functions.
Would you be willing in general to consider merging this at some point in the future? I'm assuming there would be some necessary support for define-library, or the #u8 vector syntax.
Or is R7RS something you don't want to support in any way?

[dybvig]

Supporting R7RS is a fine idea as long as doing so doesn't overly complicate the expander, compiler, or run-time system. We should also keep in mind that R7RS is not a successor to R6RS and does not replace R6RS. While we might lament this unfortunate situation and the reactionary forces that brought it about, it is what it is. Thus, we should maintain R6RS compatibility and emphasize support for R6RS over R7RS when choices must be made.

I understand some R7RS changes are at the lexical level and will require changes to the reader. Those will have to be built-in and possibly enabled via a #!r7rs marker in the input stream, similar to the existing #!r6rs and #!chezscheme markers. This is a good first step, since it would allow the construction of a separately loadable R7RS library that implements the non-lexical features of R7RS, some via wrappers as you suggest.

If we eventually decide to build in support for all of R7RS, we'll want to revisit the use of wrappers where they introduce overhead and/or negatively affect error reporting.

[weinholt]

There's another way to get R7RS code running on Chez Scheme. I have recently added R7RS support in Akku.scm, my Scheme language package manager: https://akkuscm.org/

Essentially, Akku translates define-library into one library per implementation that appears in the cond-expand clauses (the cond-expand requested in #91). There is one caveat: unquoted vectors are still syntax errors (but R7RS also supports quoted vectors, so they can simply be added to the R7RS code). The akku-r7rs package provides the R7RS standard libraries as R6RS libraries.

Here's an example of how to use it: https://gitlab.com/akkuscm/akku/wikis/R7RS-example

I've tried it with complicated R7RS libraries found in the wild and have had good success. I've passed all libraries from snow-fort.org through it, and they tend to work except the ones that have implementation-specific code.

[mnieper]

Unfortunately, the R7RS has introduced a number of incompatibilities to the R6RS. Some, like different behaviors of standard procedures (e.g., real?), are without problems because the library system allows to export different procedures by the libraries (rnrs base) and (scheme base), respectively.

Other incompatibilities are far less fortunate, like the semantics of top-level programs. In R6RS, the expansion of the right hand sides of top-level definitions have to be deferred until all definitions have been visited. In R7RS, this would result in the wrong behavior as section 5.4 of the R7RS states:

If the define-syntax occurs at the outermost level, then the global syntactic environment is extended by binding the keyword to the specified transformer, but previous expansions of any global binding for keyword remain unchanged.

So if Chez Scheme wants to support R7RS, it will need a new top-level mode (and a few more chi-* procedures in s/syntax.ss to support top-level bodies of R7RS programs and R7RS libraries.)

As the current schism between R6RS and R7RS benefits no one and seems to be harmful to the community as a whole, one may have to lobby for an R8RS, for which it makes sense to be adopted by R6RS implementations and by R7RS implementations alike.

Until this happens (I am not sure who would have to be a driving force behind it), I would very much welcome adding an R7RS frontend to Chez Scheme.

[amirouche]

Here is another PR with r7rs changes #323

[amirouche]

See also this conversation about r7rs cond expand #91