ERR5RS:Requirements and Goals
From SchemePunks
The purpose of ERR5RS is to fill a gap between the R5RS (which was last revised in 1998 to reflect a near-consensus of the early 1990s) and the R6RS (which was ratified in 2007 by 65.7% of a consensus).
Technically, the primary contribution of the R6RS was to add a new kind of Scheme program for scripting and batch-mode execution. The R6RS also adds lexical syntax, a library feature, and a set of standard libraries, but all of these new features are available only to the new style of programs. Making these new features available to traditional Scheme programs was considered to be outside the scope of the R6RS, apparently in the belief that this step could be deferred to some future standard such as ERR5RS.
Portability is the primary motivation and requirement for ERR5RS.
Portability across extended implementations of the R5RS is one goal. Without the guidance of some de facto standard such as ERR5RS, every implementation of the R5RS is likely to use incompatibly different approaches to incorporate incompatibly different subsets of the desirable features of the R6RS.
Another goal is to provide greater portability between the two incompatibly different kinds of Scheme programs that now exist. ERR5RS should make it easier for programmers to convert traditional Scheme code into R6RS libraries, and should also make it easier to convert R6RS libraries into ERR5RS code. To achieve this goal, ERR5RS should use a subset of R6RS syntax and semantics wherever possible, inventing new syntax and semantics only for essential features (such as dynamic loading of libraries into an ERR5RS top level) that were left out of the R6RS.
At the same time, ERR5RS should avoid the excesses and mistakes of the R6RS. Portability is not enhanced by making ERR5RS gratuitously difficult to understand or to implement. As the R5RS is extended, every new feature should pay its own way by improving portability of user programs more than it degrades portability by confusing programmers or by discouraging implementors from implementing ERR5RS.
That is not to say that all new features of ERR5RS must be implementable by portable R5RS code. On the other hand, designs that can be implemented easily by most implementors of the R5RS should be preferred over alternative designs that fulfill the same requirements but would be more difficult for R5RS systems to implement.
Finally, ERR5RS should show respect for Scheme's tradition by preserving backward compatibility unless there is substantial agreement that today's and tomorrow's new requirements require some of yesterday's code or books or research papers to be rewritten or abandoned.
