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:
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:
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:
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.
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:
loadevalThe 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.
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
Large Scheme
The goals of the steering committee:
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.