Lambda the Ultimate

I wish the committee all the best in this endeavour. I think it is a very brave attempt to simultaneously try and keep the Scheme community happy (not that this is possible) and drag standard Scheme towards being a useful programming language. (Many implementation of Scheme are useful; standard Scheme is not.)

Can't see it becoming Common Lisp though.

Would someone who knows more about what's involved in the split mind commenting on why this can't be done with a simple core and a number of standard libraries on top of that core?

The hardest part will be trying to find a name for their new language. I wish them luck.
I hear Scheme is taken, so is Python. Maybe they should standardize Python instead, and leave the rest of us in peace. It was always my opinion, that if you wanted, you could easily write a scheme interpreter, and go off and do whatever you like. I don't see a lot changing here, other than we will have yet another section in the O'Reilly catalog to fill the book shelves, all graced with titles like "Language Name TBD: Cookbook".
Working Group 2, I wish you the best of luck with your new language!

The proposal in the *draft* statement is NOT to develop two separate Scheme languages, but a small and large version of the same language, where the small version is a strict subset of the large one. It is not quite clear what is meant by "subset", but I take this to mean that any valid program in the small language is also a valid program in the large language.

I agree with Matt that it would be better to frame this as a distinction between a small core language and a large set of standard libraries, rather than as two languages. As this discussion already show, speaking of two languages suggests splitting the community, whereas as the goal is surely to bring the community back together, after the supposed split caused by R6RS.

Both charters say:

The programming languages developed by working groups 1 [small Scheme] and 2 [large Scheme] must be consistent, and the programming language developed by working group 1 should be a proper subset of the language developed by working group 2.

Speakin for myself only:

Roughly, small Scheme will be the successor of R5RS, whereas large Scheme will be the successor of R6RS. R6RS is defined in terms of a core and libraries, but the libraries are all mandatory, and most of them were invented by the R6RS standardization process. Many people (I speak as an R6RS supporter who mostly uses an R5RS implementation) thought R6RS was too rich, too featureful, broken in some or all of its features, and generally did not meet their needs.

It's unfortunate that the steering committee suggested that the small language is the appropriate one for things like education and research, since many so-called 'large' Scheme systems have more than proven their worth for education and research.

Sometimes schism is the best thing that could possibly happen. This is one of those times.

Scheme (by which I mean the standard, up through R4RS and maybe R5RS) met the needs of language experimenters and embedded device makers in a very important way; by remaining silent on most of the topics into which there was ongoing research.

That meant that if you had a good idea about how unicode should be supported or about supporting multiple different character encodings simultaneously, or how threads or interrupt servicing or interprocess communication ought to work, or what GUI code ought to look like, you had the opportunity to build a Scheme system using your experimental parts and try it out and see how well it worked.

The standard was a sort of umbrella under which many vastly different experimenters and designers could coexist, having created languages compatible enough with one another to support a large class of useful programs. But that class of programs mostly had to avoid the items on which there was active experimentation.

It also meant that if you needed a scheme system that was tiny or peculiar, you could do it - adopting minimal interpretations of everything the standard left optional and not going beyond it gave you an opportunity to make a Scheme system standard compliant in a tiny memory space. Or, if you had a ternary system using some deeply strange character encoding, you could make a conforming scheme for that system.

But if you weren't a language experimenter, the situation was less happy. The minute you wanted to do something the standard was silent about, you found yourself depending on a single implementation. The class of programs whose semantics were guaranteed by the scheme standard could not use, for example, concurrency or graphical user interfaces.

The fight between the faction that wanted to keep experimenting and the faction who wanted an end to experimentation and standard that would support a much larger (commercial) class of programs including all the comforts of Python, Common Lisp, etc, came to a head in R6RS, and there were lots of rude things said and bad feelings on both sides.

At the time I feared schism. But after due reflection I think it is probably the best thing that could possibly happen to Scheme at this point. R6RS was basically dead on arrival, having failed to garner the support of the most respected people in the community. A schism is the only thing that will allow both camps to move forward.

I think this division of labor could be the best thing to keep Scheme moving along while retaining its roots in simplicity.

For various reasons, I'm reminded of CTM's take on kernel languages

• First, define a very simple language, called the kernel language. This language should be easy to reason in and be faithful to the space and time efficiency of the implementation. The kernel language and the data structures it manipulates together form the kernel computation model.
• Second, define a translation scheme from the full programming language to the kernel language. Each grammatical construct in the full language is translated into the kernel language. The translation should be as simple as possible. There are two kinds of translation, namely linguistic abstraction and syntactic sugar.

Having macros in Scheme means that the distinction between libraries, linguistic abstraction and syntatic sugar can be a bit more seamless than most other PLs. However, as we found with R6RS, there are many things (such as modularity) that must be in the kernel. It will be interesting to see how that tension between simplicity and utility continues to play out in the Scheme community. I think all PL design is politics, and all politics is about compromise. The attempt to placate the hardliners with the core language and the compromisers with an extended set segregates the two camps. But, at some level, the hard work of unification still has to be done.

I'd call them the "core" and "engineering" branches of scheme.

I'd also like to see the core scheme drop some pieces of engineering baggage that R4RS picked up from the IEEE standard, eg., disjointness of primitive types. Making core scheme be something along the lines of:

• R3RS
• plus an extension of syntax-rules to allow first-class macros
• plus a minimalist record system upwardly compatible with r6rs

The semantics of engineering scheme should be given by a reference meta-circular implementation in core scheme plus libraries defs. Cf. Clinger's ERR5RS proposal (Wayback machine).

I'd like the emphasis of core scheme to be "attractive for implementors", in the sense of being open to speculative and surprising new implementations. Jeffrey Siskind has made the case strongly that this is where the true strength of scheme lies. Certainly it is where the language itself came from.

Why were none of the current steering committee members, members of the r6rs steering committee?

What is the "strategy committee"?

It may be a good idea to create a new scheme variant more suitable for larger projects and/or static code generation. However IMHO it would be better to give the Language/system a new name. How about calling it Contrive?

Thus far I've heard three possible interpretations of the distinction between the small and large versions of Scheme:

1. Abstract/Portable. The small language specifies the defining characteristics of the Scheme family of languages (e.g. lexical scope, proper tail recursion, Lisp-1, programs as data, first-class continuations, hygenic macros, interactive REPL), abstracting away all details which are outside the scope of these defining characteristics (e.g. records, data types, particular procedures, i/o, character sets). The large language is a standard instance of the abstract small language, with additional features for writing practical and portable programs (e.g. modules, specific character set, a large standard library). Other implementations of the abstract language would be members of the Scheme family, but programs written in these languages may not be portable.

2. Minimal/Rich. The small language defines a concrete but minimal Scheme programming language, no larger than R5RS, perhaps smaller, which is a strict subset of the large, rich language, in the sense that every program written in the small language is portable to every implementation of the small or large language. The small language could, for example, have fewer data types and procedures. And perhaps no macros or modules.

3. Core/Libraries. The small language defines all of the features of Scheme required for implementing the large language, but nothing else. In a particular implementation of the large language, some data types and operations may be implemented in a more efficient way than is possible using the core language alone, but in principal the core language should be expressive enough to be a platform for the entire large language. Programs written in the core language are portable across all implementations.

Which of these interpretations do you prefer? Are there others? Do we have to choose among them? Why not define them all in the next standard? (Abstract, Minimal, Core, Standard Libraries) The minimal language could be smaller than the core language.

Browsing this page and the links from here has been one of the more uplifting and hopeful moments I've had contemplating the future of dynamic languages. (Especially by contrast to my despair over the R6RS bloat.)

I wonder whether the future Small Scheme might even be an object-capability language along the lines of Jonathan Rees' W7? I also just heard about WeScheme which seems relevant.

I like this idea of splitting Scheme into a minimal educational/theoretical dialect (R3RS+W7+hygiene sounds nice!) and a "batteries included" dialect. Since the latter so similar to Common Lisp, and CLTL3 is underway, I wonder if there's any possibility of merging the two languages. Wishful thinking, I know, but I had to say it :-)

Almost no one use both small and large languages, so splitting language is just a double work and helps no one. Language + library is better. The need to split the language part is little.

Language part should be something like: R3RS + bug fix + minimalist record system + minimalist module system + well designed macro system

I think record system can be simple as vector + a spectial field for type information.

Module system provide namespace and a method to import functions from other file.

Syntax-rules is simple, but too diffcult to use and can fit into the rest of the language. Maybe syntax-case or some new macro systems can fill the need.

I don't think Unicode is a problem if case sensitive, but interpreters/compilers should accept all characters the machine uses.

More powerful functions can put in a "standard library", like the C language does. The library can update more frequency.

That meant that if you had a good idea about how unicode should be supported or about supporting multiple different character encodings simultaneously, or how threads or interrupt servicing or interprocess communication ought to work, or what GUI code ought to look like, you had the opportunity to build a Scheme system using your experimental parts and try it out and see how well it worked.

The standard was a sort of umbrella under which many vastly different experimenters and designers could coexist, having created languages compatible enough with one another to support a large class of useful programs. But that class of programs mostly had to avoid the items on which there was active experimentation.

An SICP-style teaching language shouldn't have second-class objects — notably, hygienic macros. (So-called "first-class macros" are, of course, just second-class macros plus a type system to take over responsibility for shaping the second-class restrictions imposed.) It's been my observation that when students in an SICP-style course have trouble with certain features of Scheme, it's because the novice student expects things to work in a simple uniform way whereas Scheme works in an ad hoc way, like the and and or operators being second-class. Fexprs eliminate that non-uniformity; macros exacerbate it. I've thought for years that the R5RS abrogated the right to claim the philosophy of eliminating-weaknesses-and-restrictions when it adopted hygienic macros into the language.