Lambda the Ultimate

[T]his document describes a proposed ratification procedure. Discussion of this procedure is taking place on the ratification-discuss@r6rs.org mailing list. The discussion period ends on April 15th.

The Scheme Standardization Charter says that after the Editors submit a proposed final draft, "the Steering Committee should then choose either to finalize the draft or to restart the review process." This document describes how the Steering Committee will make that decision.

The ratification process proposed is somewhat unusual (e.g., a no vote will need to include an explanation), but this may change due to the comments sent to the mailing list.

I think many LtU readers should consider taking part in the vote, since as programming languages aficionados we cetainly have a stake in Scheme. Now is the chance to influence the procedural aspects of the ratification process.

It would be of interest to me to see a codification of the impact language style has on ancillary tools. For example, I want my IDE to show me wherever a given variable is used. You can try to do that with just textual searches, but if the language allows runtime aliasing then you are presumably going to have a more difficult time of statically generating the relevant information about variable use. Or, you are going to have to restrict the breadth of information generated. (IntelliJ actually does do something along these lines for Java, although I suspect it doesn't follow aliasing chains?)

I'd guess that language styles are more-or-less amenable to particular such issue. I guess I see this as a way of guiding myself and others towards understanding another angle on why e.g. functional programming matters, or mutable state is evil, etc.