The Scheme Language Is to Be Split in Two

Posted by Abel Avram on Aug 21, 2009

Sections

Development,

Architecture & Design

Topics

Architecture ,

Language ,

Language Design

Tags

Scheme ,

LISP

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 Revisedⁿ Report on the Algorithmic Language Scheme, abbreviated RⁿRS, is actually used. The latest revision is R⁶RS 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.

1. Back to top

   Scheme should be implemented on Parrot VM

   by Jérôme Radix

   To catch up with other languages, the only Scheme implementation that should be used is one that runs on Parrot VM. With such implementation, Scheme instantly benefits from all Perl modules of CPAN (16406 modules and counting) or other languages modules. See the languages page on Parrot VM site for a list scheme implementation on Parrot VM.

   Reply

2. Back to top

   Re: Scheme should be implemented on Parrot VM

   by Troels Knak-Nielsen

   I don't think that a Scheme running in a VM, based largely on foreign libraries, is the best move. We already have Clojure filling that space. One of Schemes strengths is that you can build applications from the bottom up. If a large part of the libraries are external code, you loose some of this.

   Reply

3. Back to top

   Re: Scheme should be implemented on Parrot VM

   by Frederick Polgardy

   The VM that runs the mythical Perl 6 is the standard against which new language implementations should be judged?
   
   Anyway, what does VM have to do with the specification of the language itself? The whole point of a language spec is that it gives different implementors a standard to conform to. Forcing a language to have only one implementation is a terrible idea.

   Reply

• Older >