[ZT] The Scheme Language Is to Be Split in Two

win_hate

原文鏈結(jié) http://www.infoq.com/news/2009/08/Scheme-Split-in-Two;jsessionid=07D949A4580ACA1530DE88AE67246C62

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.

win_hate

官方聲明： http://scheme-reports.org/2009/position-statement.html

Scheme Steering Committee Position Statement

Draft - 20 August 2009

Programming languages are like sharks. When they stop moving forward, they die.

Scheme has never stopped moving — not completely. It's been more of a moving target than a fixed language. Scheme is a "dynamic language" in more ways than one.

The purpose of this article is to explain the position of the Scheme Language Steering Committee:

    * how we see the state of the Scheme programming language today;
    * where we believe Scheme is going, and should go;
    * what we believe our role to be, in serving the Scheme community.

A programming language stays healthy and vibrant by virtue of being used. When it comes to using Scheme, however, the Scheme community has rarely missed an opportunity to miss an opportunity.

The diversity of Scheme's constituencies has been a problem, but has also been one of Scheme's greatest strengths:

    * educators
    * language designers
    * programmers
    * implementors
    * hobbyists (who write Scheme implementations just for fun)

The danger

While the Scheme community has many constituencies, we believe that one primary purpose of a programming language is to program. A programming language is a notation that's supposed to help programmers to construct better programs in better ways:

    * quickly
    * easily
    * robustly
    * scalably
    * correctly

A language that doesn't enable programmers to program is, in the end, doomed to irrelevance.

Alas: Scheme has the unhappy distinction of being the world's most unportable programming language. It is almost misleading to call Scheme a "programming language;" it would be more accurate to characterise Scheme as 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.

Note that this list of features does not include exceptions, modules, concurrency, unicode text, or mechanisms for defining union types, record types, or abstract data types – yet these too are often important.

As things stand now, 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.

This has led to 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.

To name names, compare this state of affairs to languages such as Perl, Python, C, or Ruby. To Scheme programmers, these languages are technically inferior – nonetheless, literally billions of dollars of software and IT services have been and are being constructed with these tools. Real-world success matters: it is the means by which vibrant user communities grow; it is the social context that generates the resources that keep languages alive and thriving: money, people, "how to" books, implementations, software libraries, and so on and so on.
The IEEE, R5RS, and R6RS Standards

We have a history of progress on which to build.

IEEE Standard 1178 was approved by about 95% of 59 voters.

The R5RS extended the IEEE standard in several ways:

    * high-level hygienic macros
    * multiple return values
    * load
    * eval

The R6RS was approved by about 66% of 102 voters. It introduced a more static language organized around libraries, along with too many other new features to list here.
Two languages

We believe the diversity of constituencies justifies the design of two separate but compatible languages, which we will (for now) call "small" and "large" Scheme.

Small Scheme

    * Constituencies: educators, casual implementors, 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, implementors
    * Think "R6RS with a happier outcome."
    * ~ 75% supermajority to be required for final ratification

The goals of the steering committee:

    * we don't standardise or otherwise define the language;
    * rather, we oversee the process of its definition.
    * …and, when necessary, we may steer the effort a bit.

That is, we enable the Scheme community to prosecute the development of the language – its definition, growth, extension, standardisation 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.

An irony is that research by the Scheme community has led to the development of two key technologies that should enable great portability: hygienic macros and module systems that include macro definitions in their managed namespaces. We aim to realize that promise.