Revising R6RS

[mnieper]

Since its coronation in 2007, R6RS has remained a viable dialect for Scheme, both in research and for doing practical programming. The Scheme standardization process has moved on in the form of R7RS-small and a number of SRFIs for R7RS-large, but these later standards are successors of R5RS and do not supersede R6RS, so R6RS has remained frozen from its inception.

As the R6RS has been written under the assumption that it won't be the last revision in its line of dialects, I would like to explore the willingness of the community to invest in a revision of R6RS. Thanks to the library versioning system of R6RS, such a revision can be fully compatible with R6RS by using the library versions (6 1) instead of (6) and by adding the lexical syntax #!r6.1rs analogous to #!r6rs. (I am calling the revision 6.1 in order to signal that it does not step on the toes of R7RS but will be a successor to R6RS instead.)

The goals of such a revision can be the following:

• Incorporate the errata from www.r6rs.org into the report.
• Add the "missing" type predicates as mentioned in Section 7.1 of Chez's user manual.
• Signal newcomers to the Scheme language that R6RS is still alive and hasn't been superseded by R7RS.
• Revive general interest.
• Reduce some incompatibilities with R7RS. Depending on where R7RS-large heads, this may make a reunification around a hypothetical R8RS possible.
• Extend the language according to experience since 2007.

Concerning language extensions, I think the following options could be discussed:

• Syntax parameters.
• Identifier properties.
• Delimited Continuations.
• Continuation Marks.
• Promises à la SRFI 155, which don't need delay-force.
• Datum labels in reader syntax.
• Optional basic threading library with specified semantics when available.
• Removal of seemingly artificial restrictions (like the order of definitions and expressions in (library) bodies).
• Standardizing the naming convention (srfi :nnn) of SRFI 97.
• Ellipsis and underscore as literals in syntax-case.
• Guile's with-ellipsis in order to be able to support the syntax-rules of SRFI 46/R7RS.
• Parameter objects as in SRFI 18/SRFI 39 with tail context guarantee of Racket.
• Adding a few POSIX-like OS-interface procedures, like accessing of environment variables as in SRFI 98.
• Add a new data structure like HAMTs to support purely functional "hash tables". (This can then be used for implementing the continuation marks from above.)
• Chez's local modules and imports and Chez's meta definitions.
• include and cond-expand (or meta-expand) expressions.
• Make pairs in rest lists immutable.
• Incorporate (some of) R7RS's lexical syntax for identifiers (including |...| and ..1).

What do you think? In order for such an attempt to be meaningful, it is important that the main R6RS implementations will endorse such a hypothetical R6.1RS. This includes first and foremost Chez Scheme, but also Racket should be willing to move its R6RS mode forward. We shouldn't forget about GNU Guile and the relatively new Loko either.

The first revision of R6RS does not have to be monumental. An incremental approach and relatively fast delivery seem the better choice.

Thanks!

Marc

PS Please excuse this misuse of Chez's issue tracker in order to reach an important part of the R6RS community.

[johnwcowan]

As the chair of the R7RS-large working group, I support this effort.

Here are some further suggestions for base-level R6.1RS libraries along with sample proposals:

1. Sockets: SRFI 106. This allows portable clients (servers are not as important) both for connecting to local servers like database engines, and for accessing Internet resources. Standardizing on a simple HTTP/HTTPS client would also be a Good Thing.

2. Standard FFI: PFFI. With this we can make Posix SRFI 170 and related proposals portable too.

I think it's very important to standardize these things; the detailed proposals are just indicative. I only wish they were so straightforward for R7RS-large.

[mnieper]

I want to update you on this topic briefly: I asked the Scheme Steering Committee for their support for this endeavour. They will discuss the topic at their next meeting (probably by the end of October). I hope we get a positive reply.

[LiberalArtist]

The behavior of / with exact 0 (see https://github.com/cisco/ChezScheme/issues/400 and https://github.com/cisco/ChezScheme/pull/773) seems worth adding to this list.

[mnieper]

Thank you for pointing this out, @LiberalArtist.

PS The Scheme Steering Committee hasn't made up their mind yet, so I cannot tell more in this direction at the moment. While Scheme does not belong to anyone, and we are free to take any action we want, it will be better if we have broad support.

[mnieper]

This is another place where a revision of R6RS can improve the standard:

https://github.com/cisco/ChezScheme/blob/main/s/enum.ss#L27