A proposal for an Extended R5RS Scheme
Moved content over from Extended R5RS
Date: Fri, 31 Aug 2007 07:14:51 -0700 (PDT) From: William Clinger <email@example.com> Subject: [Junta] Extended R5RS Scheme
Although many users and implementors of R5RS Scheme have no intention of abandoning R5RS-style programs for R6RS-style, some R6RS features would be useful additions to the R5RS and are likely to make their way into implementations of the R5RS and into R5RS programs.
There is an urgent need for community consensus on how to do this, lest the R6RS precipitate a crisis of portability in the R5RS world as every group of implementors chooses different ways to extend their systems with different subsets of R6RS features.
You have an opportunity to meet this urgent need. It may not be as much fun as refactoring the R4RS or R5RS to preserve Platonic ideals, but creation of a successful process for coordinating the R5RS world's constructive response to R6RS would be a real service, and would establish credibility and good will that would further your other goals.
You can do this without reinventing wheels. The R5RS already exists, and the R6RS will soon exist also; both give you explicit permission to copy them "in whole or in part without fee" and to use them "as a starting point for manuals and other documentation, modifying it as necessary." The SRFI process is well-established, and there are reference implementations for several pieces of the R6RS, with more on the way. In particular, Andre van Tonder's implementation of libraries, syntax-case, and explicit renaming macros should now run in any implementation of R5RS Scheme.
It seems to me that four things are needed for this project, which I'll refer to (for now) as Extended R5RS Scheme:
- a lexical syntax that extends the overly complex but still-inadequate lexical syntax of the R5RS by defining a subset of the R6RS syntax on which users of Extended R5RS Scheme can rely;
- a subset of the R6RS library form, along with some kind of load-library or require feature;
- a collection of libraries that make appropriate subsets of selected R6RS standard libraries available to programs written in Extended R5RS Scheme;
- SRFIs for each of the above, including reference implementations.
- Perhaps a decision on what to do with the R6RS changes for bodies, which include letrec* semantics for internal definitions, new behaviours of internal let(rec)-syntax, addition of internal define-syntax, and the tighter specification of the expansion process for bodies. This also affects library and program syntax, which R6RS unifies with that of bodies. (AvT)
As an implementor of Larceny, I must design the first three bullet items above in the very near future. I'd like some help. Ideally, I'd like for you to do the work for me, not so much because I'm lazy (though I am) as because these things will have more legitimacy and support if they come from users than from me.
Finally, let me note that Extended R5RS Scheme should enjoy support even from implementors who commit themselves to the R6RS. Indeed, several of the R6RS editors are on record as saying the R6RS was not intended to wipe out R5RS-style programs or interactive top levels, which are of particular importance for education. The development of Extended R5RS Scheme might even provide a practical migration path from the R5RS to some future standard that supersedes both the R5RS and the R6RS while unifying the Scheme community to a degree that might be hard to imagine at this moment.
(End of email. Hga 16:06, 31 August 2007 (PDT))
 Related pages:
- http://lists.scheme-punks.org/listinfo.cgi/err5rs-scheme-punks.org - mailing list for ERR5RS
- ERR5RS:Acronym - what ERR5RS stands for
- ERR5RS:Requirements and Goals - what ERR5RS should accomplish
- ERR5RS:Artifacts - what ERR5RS should produce
- ERR5RS:Milestones and Target Dates - when those things should be accomplished or produced
- ERR5RS:Responsibilities - and by whom
- ERR5RS:A Concrete and Conservative Proposal
- ERR5RS:Point Counterpoint
- ERR5RS:Polling Place - Decision Making