This page is an attempt to summarize the underlying philosophical objections that led to rejection of the R6RS. This page was originally written by Daphne Preston-Kendal, but note that she and any other contributors to this document do not necessarily agree with the objections here, they are just documenting them.
This document is still a work in progress.
See also John Cowan’s SixRejection for a summary of the individual issues and the actual votes against for the actual source.
High-level features without clear or well-designed low-level equivalents
A number of objections concern the fact that R6RS adopted features which
- The record type system was frequently mentioned, in particular the relationship between the syntactic and procedural layers, and that the concept of record constructor descriptors is too complex for the problem it solves
Unnecessary libraries/features
Some libraries adopted by the R6RS were objected to as not being poorly-designed from a flexibility perspective, but just as being unnecessary given the design and existing features of Scheme.
- Library versioning
(rnrs enums (6))
Rejection of existing Scheme libraries
Libraries already designed in the SRFI process, or even adopted in previous RnRSes, were ignored and redesigned by the R6RS committee for no apparent reason.
This concern applies to
- the
(rnrs lists (6))library, which completely ignored precedents such as SRFI 1- R7RS Large position: SRFI 1 has been adopted as
(scheme list), pending some changes by Committee C
- R7RS Large position: SRFI 1 has been adopted as
- the
(rnrs io ports (6))library, which replaced the R5RS idea of i/o procedures entirely syntax-casein the form adopted by R6RS, which ignored existing approaches such as explicit renaming and syntactic closures (note that e.g. SRFI 72 provides asyntax-casewhich is far more similar to the approach used by explicit renaming)- R7RS Large position:
syntax-casehas been adopted in its R6RS form, though there are discussions about alternative ways of expressing its semantics
- R7RS Large position:
Hamstringing implementations
Some features and requirements adopted by the R6RS were felt to unnecessarily hamstring implementations in their ability to adopt different implementation strategies.
- the suggestion (RFC 2119 SHOULD) that
string-refoperate in O(1) time was felt to restrict implementations to flat UTF-32 arrays, disallowing UTF-8 or ropes- R7RS Large position: see #30
- the requirement implied by the
string-normalize-*procedures that implementations cannot internally store strings in a single normalization form- R7RS Large position: see #41
- the requirements on a Scheme’s syntax model imposed by the adoption of the R6RS form of
syntax-case(but it is worth noting that adopting any other clear semantics of procedural macros would impose an equal barrier to alternative strategies)- R7RS Large position:
syntax-casehas been adopted in its R6RS form
- R7RS Large position:
-
FAQ about R7RS Large