The Scheme Steering Committee is proposing the split of the Scheme language in two which temporarily are called Small Scheme and Large Scheme.
Scheme was invented in the ‘70s by Guy L. Steele and Gerald Jay Sussman as a dialect of Lisp, and has gone through several revisions. The IEEE 1178-1190 Standard officially define the standard, but the Revisedn Report on the Algorithmic Language Scheme, abbreviated RnRS, is actually used. The latest revision is R6RS and was approved in 2007. Starting from the analogy “Programming languages are like sharks. When they stop moving forward, they die,”, the steering committee is attempting to push Scheme ahead.
The main problem the committee noticed was the fact that Scheme is not really a programming language but
a family of dialects, all loosely related by the common features of lexical scope, dynamic typing, list structure, higher-order functions, proper tail-recursion, garbage collection, macros, and (some form of) s-expression based lexical syntax.
And indeed, Wikipedia lists a large number of Scheme implementations: Bigloo, Chez Scheme, Chicken, Gambit, Gauche, Guile, Ikarus, JScheme, Kawa, Larceny, MIT/GNU Scheme, Mosh, PLT Scheme, Pvts, RScheme, Scheme 48, SCM, SISC, Stalin, STk, STklos, TinyScheme, Ypsilon. According to Scheme Committee Position Statement, the problem with these dialects is that
a programmer who wishes to write a significant program in "Scheme" must immediately commit to some specific implementation of Scheme: Bigloo, say (and its module language, exception system, s-expression grammar, etc.), or perhaps PLT Scheme (and its module language, etc., etc.), or perhaps one of the other competently engineered Scheme implementations. But this, in turn, means that applications cannot be executed across multiple implementations. More importantly, libraries or modules of code, such as URL parsers, network-protocol stacks, regular-expression implementations, and so forth, wind up stranded within the realm of a specific implementation – which, in turn, means that Scheme programmers are constantly building "from scratch," rather than being able to benefit from the fruits of each others labors.
The end result is that there is
a great deal of unnecessary fragmentation and duplication of effort: instead of standing on the shoulders of previous programmers, Schemers step on each others' toes.
The Committee considers the fragmentation comes from the diversity of Scheme’s constituency: educators, language designers, programmers, implementers, hobbyists. To solve the problem they propose two compatible yet separate languages:
Small Scheme
- Constituencies: educators, casual implementers, researchers, embedded languages, "50-page" purists
- Think "IEEE/R5RS brought up to the current date."
- ~ 90% supermajority to be required for final ratification
Large Scheme
- Constituencies: programmers, implementers
- Think "R6RS with a happier outcome."
- ~ 75% supermajority to be required for final ratification
The Steering Committee is not going to standardize the languages but rather to
enable the Scheme community to prosecute the development of the language – its definition, growth, extension, standardization and implementation. Our chief mechanism is by granting charters to various committees that will carry out the actual tasks, and stamping the results of these efforts with our imprimatur.
Two working groups have been started and draft documents created, Small Scheme Group and Large Scheme Group, but the membership of these groups are not established yet. The purpose of Small Scheme is described as following:
This small language will encapsulate the fundamental features of Scheme. Its target uses include education, programming language research, small embedded systems, and embedded scripting languages, where it is appropriate to use a lightweight language at the semantic level and/or in the implementation.
According to the Large Scheme working group draft
This large language should address the practical needs of mainstream software development. …
The language developed by working group 2 must include support for macros and modules/libraries.
When deciding which features to include in the large language, working group 2 should consider all features provided by R6RS Scheme, and all criticisms of those features.
Working group 2 may also consider whether it is practical to add new features to support networking, threads, internationalization, foreign-function interfaces, et cetera. Working group 2 is encouraged to propose new working groups for any new features that it considers desirable but cannot pursue without risking the timeliness of its primary mission.
The two groups are going to coordinate their efforts and a final draft proposal is to be produced after 18 months for Small Scheme and 24 months for Large Scheme. The actual names of the languages remain the be decided.