What’s the point of a Scheme standard?

Here is a copy of Joe’s post on r6rs-discuss:

What’s the point of a Scheme standard? I can think of a number of uses. A guideline for new Scheme implementations. A touchstone to distinguish a “real” implementation from a wanna-be. A reference point for academic papers so they don’t need to devote an appendix to describing the semantics of their language. A “weighty tome” that adds gravitas to one’s bookshelf. The reference for nitpicking language lawyers. A wishlist of features that would be nice to have. But I think the most important thing for a Scheme standard to be is this: An agreement between language implementors and programmers that specifies the minimum functionality that an implementor is expected to provide and the maximum functionality that a programmer can assume is available from any system that claims to meet the standard. Naturally, any implementation can provide more functionality than is prescribed, and no one expects any particular program to use all possible functionality.

Additional functionality is the way the language has evolved. The different implementations would add extra features for various reasons. Since these features were developed independently, there were often incompatible. Some of the differences were simply idiosyncratic, others, however, were caused by deliberate decisions about design. When a feature proved its utility, the programmers would put pressure on the implementations to add the feature. When a useful feature was incompatible between different implementations, an effort was made to reconcile the incompatibilities. In the early days, this could be accomplished by getting all the implementors in the same room and letting them argue. This isn’t practical anymore.

The reason I put together my spreadsheet of Scheme implementations was not so that I could argue that any one is better than another. My purpose was altogether different. I wanted to get an idea of what subset of Scheme implementations are likely to affect or be affected by a new standard. Most of these Scheme implementations are at least R5RS compatible, and all of them extend the language in various ways. Some of these extensions are quite common across a large number of implementations.

If every Scheme implementation implemented an extension to the language in the same way with the same semantics, I can hardly there being much opposition to declaring this to be a standard feature. It would be a de-facto standard and it would require zero effort on the part of implementors if it became a de jure standard. On the other hand, if no Scheme implementation implemented a particular extension (say, for example, SRFI-49), there shouldn’t be an enormous outcry if the feature were omitted from the standard. The issue becomes more complicated when a feature is available in only a subset of the implementations.

Let’s take a particular example: SRFI-8 (special form receive for multiple values), is available in 21 implementations. The SRFI is trivially implemented with an R5RS syntax-rules macro. It seems to me that this would be a prime candidate for inclusion in an upcoming standard. It would require very little work on the part of implementors (unless, of course, they did not support multiple values at all or did not have syntax-rules), and the aesthetic issue (introducing a trivial special form) is fairly minor.

SRFI-36, on the other hand, is only available in three implementations. It defines a hierarchy of I/O exceptions. It would be non-trivial to add this to an implementation that had no exception hierarchies, or to one that had incompatible exceptions. It would be a poor candidate for inclusion.

What about something like SRFI-23? Here’s where things get tricky. There are only seventeen implementations that support SRFI-23, but included in those seventeen are PLT Scheme, MIT Scheme, Gambit, Gauche, Chicken, SCM, SISC, and Scheme48. It’s not universal, but it is very widespread. Or what about SRFI-48? It is available in Larceny, Scheme48, partly in Kawa, STKlos, PLT Scheme, Iron Scheme, and S7. If you use MIT Scheme, Gambit, Gauche, Chicken, SCM or SISC, you’re out of luck.

The tiers that I had published previously were not there because of my preferences. They were there as a rough guide to determine how much support is needed or given for a particular feature set. Your new special form may be the niftiest hack since McCarthy’s amb, but if you can’t get buy-in from PLT, MIT, Gauche, Guile, Gambit, Chicken, Scheme48, and SCM, it just cannot be called a standard. Alternatively, if the “Top Ten” buy into your ideas (whatever the “Top Ten” might be), then it will probably be one of the less supported implementations that will have to admit that they do not adhere to the standard.

So which Schemes are the leaders of the pack?

How Small Can a Scheme Implementation Be?

How small does it have to be? Chibi Scheme does syntax-rules in 174 lines of Scheme, layered over explicit renaming. Indeed, Chibi does essentially all of R5RS in 4822 lines of C + 708 lines of Scheme.

— John Cowan
Scheme 9 from Empty Space is also very small from what Nils said.
(via this thread in r6rs-discuss, I have the email but can not find the archive of it)

Coding for Humans: Annotated Code View in an IDE

Here is a post where Jordan explains what he wants to accomplish in the DrScheme IDE; basically he wants to be able to customize code in the IDE by annotating it, allow the annotations to be displayed only, while having the code run in mzscheme as expected.
Here is a screencast that he made which demonstrates his goal.
Very interesting!
(via plt)

A Dan Weinreb talk about enterprise software, Lisp, and Scheme

Here is a good talk by Dan Weinreb about enterprise software, Lisp, and Scheme. Here are some parts that I found interesting:

  • “There must be some really hard problem that we can profitably solve”: Generally good advice from a group of PhD students looking to apply their expertise who would go on to start up Dan’s employer.
  • “Sometimes syntax does matter”: Indeed!
  • They use Clozure CL for their new app; and SBCL for their old one.
  • “[We] provison for static type checking: we have macros to do checking, and also for defining functions that are typed. We use them at major module interfaces.” Dan’s reply when asked if they use static type checking anywhere in the system. This is how PLT’s contract system works.
  • The ILC ’09 videos will get posted; seriously.
  • PLT Scheme kudos were given.
  • The future of Lisp is unifying the efforts of Common Lisp and Scheme.
  • That unification might very well come on the JVM (good libs, large investment in runtime).

Still wondering why only five people showed up for this talk (excluding Norvig).
(via tc-lispers)

R7RS planning has begun

Here is the announcement and here are the details. Depending on how you read the materials, you will either think that this is a perfect solution that will keep everyone happy without forking the language, or you will think that the language is getting forked, followed by varying levels of hope about how said forking will turn out. Here are some highlights:

From “Position statement on Scheme language evolution”

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.

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.

From “Draft charter for working group 1”

In a nutshell [the “small”] language should remain true to the language design precepts found in the RnRS introduction (“Programming languages should be designed not by piling feature on top of feature, …”).

If the Steering Committee concludes that specifications of the small language are not supported by at least 90% of a representative electorate, then those specifications will not be approved.

[The working group will produce] a draft suitable for final approval after 18 months

From “Draft charter for working group 2: the “large” language working group”

This large language should address the practical needs of mainstream software development.

If the Steering Committee concludes that specifications of the large language are not supported by at least 75% of a representative electorate, then those specifications will not be approved.

[The working group will produce] a draft suitable for final approval after 24 months

Although their justification for this approach, that small Scheme is for educators and big Scheme is for real-world work, is flawed, their approach will probably make everyone happy in the end. We’ll know in two years.