Lambda the Ultimate

This ratification discussion is not about making changes to the content of R6RS (at least not directly). Anyone who wanted a say in the content of R6RS has already had the opportunity to comment, most recently during the public comment period which began in September and ran through March 15th. Prior to that, various R6RS SRFIs were published for public feedback via the SRFI process, going back to July 2005. The most recent draft of R6RS, v5.92, incorporates many changes in response to public comments. Another such draft will be released now that the recent comment period is officially over.

What, they got tired of grumbling about PLT Scheme? How things change.

Later: perhaps that was excessivley grumbly. Point being, if you have two people in a room you'll find a disagreement somewhere. When writing standards you have to be prepared to annoy some people otherwise you'll never get finished. Likewise, no-one should expect Scheme to be their pet language.

Actually, since the discussion now is about the ratification process, the real question is whether this can be your pet ratification process...

Indeed, however, I've seen Riastradh's work, and I trust his judgement when it comes to Scheme.

If you want to discuss this on LtU, please add content. Either links or discussion. Preferably both.

...is that there are so many of them to choose from.

Seriously, there are quite a few people whose judgment I trust when it comes to Scheme. Of course, they don't all agree about how Scheme should evolve, or even on what "Scheme" is. It takes time, effort, and patience to reach any kind of agreement on many of the issues involved. Even with such an investment, the payoff to any individual participant may be small, in terms of adoption of the features they consider important, or even exclusion of features that they dislike. This can, quite understandably, discourage some people from participating.

There are an astonishing number of competing constraints in the development of a standard for Scheme. Many ideas which may be great ideas for an individual Scheme implementation aren't necessarily suitable to be imposed on all Scheme implementations by a standard such as R6RS. For such ideas, the best approach may be to ensure that the standard doesn't preclude such extensions in individual implementations. But that can lead to underspecification, which even while serving some useful purpose, also has negative consequences with respect to the portability of code between Scheme implementations.

The flip side of this, of course, is that supporting greater portability can require overspecification, particularly in the context of a language like Scheme, which has historically been greatly underspecified in many important areas. These and other important issues often aren't considered in the kind of discussions that have occurred on the #scheme channel.

The Scheme Steering Committee, and the earlier Strategy Committee, designed a process to support the necessary discussion and deliberation, in a way that didn't suffer from the deadlock problems that had occurred during the development of previous Scheme reports. That process may not be perfect, but as Ehud has pointed out, the upcoming ratification discussion shows that even the process by which Scheme standards are developed is itself subject to discussion and evolution.

I encourage anyone who feels that they have something to contribute to take the time to do so. Even if an individual idea isn't adopted, simply raising it can have an influence on the ideas of others, and on editorial decisions. The people whose judgment has most influenced the R6RS document and process are those who've taken the time to participate, and it could hardly be otherwise.

There are an astonishing number of competing constraints in the development of a standard for Scheme. Many ideas which may be great ideas for an individual Scheme implementation aren't necessarily suitable to be imposed on all Scheme implementations by a standard such as R6RS. For such ideas, the best approach may be to ensure that the standard doesn't preclude such extensions in individual implementations. But that can lead to underspecification, which even while serving some useful purpose, also has negative consequences with respect to the portability of code between Scheme implementations.

This is true for practically any language, of course.

In general, yes. But the Scheme case is fairly unusual, in that there are a set of implementations that have significant incompatibilities with each other, and a language definition (R5RS) which is sufficiently underspecified to allow all of these implementations to be considered essentially conformant. In this situation, adding needed standardization of some fairly basic features, like records or modules, inevitably means overlap or conflict with existing features in existing implementations.

Many other languages either have a single canonical implementation, or at least have a much more centralized approach to the initial development of new features, so they don't face the same degree of tension between underspecification and portability. For these languages, underspecification to the degree found in RnRS to date is not often considered either necessary or desirable.

There are exceptions, of course. The most obvious one is probably Lisp during the standardization of CL. However, CL seems to have had difficulty moving forward with further standardization itself, so that example underscores my point. Scheme also has some other fairly unique challenges when it comes to standardization, but doing justice to them all would require something of an essay.