Too Much is Not Enough: The Revised^6 Report on the Algorithmic Language Scheme (R6RS)

On September 26, 2007, the Revised^6 Report on the Algorithmic Language Scheme was released. Normally, a new standard for Scheme is greeted with applause, but this time, the revision sparked a great controversy. The Scheme community became divided between pro-R6RS and anti-R6Rs factions, and some members even decided to leave programming language theory completely at least partly because of this change. As Nils M. Holm has mentioned,

A lot has happened since the release of the previous edition of Sketchy LISP. The Six’th Revised Report on the Algorithmic Language Scheme (R⁶RS) was ratified and Scheme is no longer the language it used to be.

Why not? Consider this graph provided by Grant Rettke. Looking at the graph, it is remarkable how there is a sudden break in continuity between most of the members of the list of authors for R2RS – R5RS, and those for R6RS. Specifically, the following authors were in common between R2RS – R5RS, but suddenly disappeared in R6RS:

Chris Hanson
Chris Haynes
Dan Friedman
David Bartley
Don Oxley
Eugene Kohlbecker
Gary Brooks
Hal Abelson
Jonathan Rees
Kent Pitman
Mitchell Wand
Norman Adams (or Norman I Adams IV, assuming this name references the same author)
Robert Halstead
William Clinger

Instead, we suddenly see the appearance of the following authors for R6RS, who had never appeared in any of R2RS – R5RS:

Anton Van Straaten
Jacob Matthews
Matthew Flatt
Michael Sperber
Robert Bruce Findler

In fact, the only person common in the lists between R3RS – R5RS (according to the chart, he was not an author for R2RS) and R6RS is Kent Dybvig.

What happened to all the previous authors, and who are these new authors?

Apparently, at least some of the previous authors quit the board, possibly because of a disagreement over the new standard. As for the new authors, I know of both Matthew Flatt and Robert Bruce Findler from PLT Scheme. They are members of the PLT Research Group, and they regularly post on the plt-scheme mailing list. (They have both been very helpful on many occasions, so I have no qualms against them personally; I am just trying to analyze their motivations for R6RS.) They are both also among the authors for HtDP. They are also among the co-authors for the influential paper “The Structure and Interpretation of the Computer Science Curriculum.” According to that paper (see pp. 6-7, in section “3.1 Functional and object-oriented programming”), they write as follows:

Functional programming and object-oriented programming differ with respect to
the syntax and semantics of the underlying languages. The core of a functional lan-
guage is small. All a beginning programmer needs are function definition, function
application, variables, constants, a conditional form, and possibly a construct for
defining algebraic types. In contrast, using an object-oriented language for the same
purposes requires classes, fields, methods, inheritance in addition to everything that
a functional language needs….

Using a functional language followed by object-oriented language is thus the
natural choice. The functional language allows students to gain confidence with
program design principles. They learn to think about values and operations on
values. They can easily comprehend how the functions and operations work with
values. Better still, they can use the same rules to figure out why a program pro-
duces the wrong values, which it often will. Teaching an object-oriented language
in the second course is then a small shift of focus….

I.e., Flatt and Findler believe that teaching functional programming should be followed by teaching object-oriented programming. This concept, however, is not shared by all educators. In particular, Paul Hudak, one of the designers of the Haskell programming language, writes on the Haskell-Cafe mailing list as follows on a related issue (see “[Haskell-cafe] a regressive view of support for imperative programming in Haskell“:

All of the recent talk of support for imperative programming in Haskell
makes me really nervous. To be honest, I’ve always been a bit
uncomfortable even with monad syntax. Instead of:

do x <- cmd1
y <- cmd2
…
return e

I was always perfectly happy with:

cmd1 >>= \x->
cmd2 >>= \y->
…
return e

Functions are in my comfort zone; syntax that hides them takes me out of
my comfort zone.

In my opinion one of the key principles in the design of Haskell has
been the insistence on purity. It is arguably what led the Haskell
designers to “discover” the monadic solution to IO, and is more
generally what inspired many researchers to “discover” purely functional
solutions to many seemingly imperative problems. With references and
mutable data structures and IO and who-knows-what-else to support the
Imperative Way, this discovery process becomes stunted.

Well, you could argue, monad syntax is what really made Haskell become
more accepted by the masses, and you may be right (although perhaps
Simon’s extraordinary performance at OSCOM is more of what we need). On
the other hand, if we give imperative programmers the tools to do all
the things they are used to doing in C++, then we will be depriving them
of the joys of programming in the Functional Way. How many times have
we seen responses to newbie posts along the lines of, “That’s how you’d
do it in C++, but in Haskell here’s a better way…”.

While Hudak contrasts imperative vs. functional, as opposed to object-oriented vs. functional, the basic issue is the same: Should functional programming be treated as a separate paradigm by itself (as “the Functional Way” vs. “the Imperative Way” (or maybe even “the Object-oriented Way”)), or should it be combined with a different paradigm (be it imperative or object-oriented, the issue is the same). Or even (according to some educators), should there even be an issue of “paradigm” at all?

This is an issue of basic teaching philosophy. As an example of the third viewpoint, Shriram Krishnamurthi writes on the plt-scheme mailing list as follows (see “[plt-scheme] Re: More pedagogic stuff“:

Besides the simplistic
reasoning, I am opposed to the whole idea of programming languages (or
even much of programming) being organized around “paradigms”. Here is
a short and intentionally somewhat provocative article that I recently
wrote about this:

http://www.cs.brown.edu/~sk/Publications/Papers/Published/sk-teach-pl-post-linnaean/

In the referenced page, Krishnamurthi writes as follows:

Programming language “paradigms” are a moribund and tedious legacy of a
bygone age. Modern language designers pay them no respect, so why do our courses
slavishly adhere to them? This paper argues that we should abandon this method of
teaching languages, offers an alternative, reconciles an important split in programming
language education, and describes a textbook that explores these matters.

In the referenced paper (see “Teaching Programming Languages in a Post-Linnaean Age,” Krishnamurthi writes (see p. 1, third paragraph):

Most books
rigorously adhere to the sacred division of languages into “functional”, “imperative”, “object-oriented”,
and “logic” camps. I conjecture that this desire for taxonomy is an artifact of our science-envy from the
early days of our discipline: a misguided attempt to follow the practice of science rather than its spirit.
We are, however, a science of the artificial. What else to make of a language like Python, Ruby, or Perl?
Their designers have no patience for the niceties of these Linnaean hierarchies; they borrow features as they
wish, creating melanges that utterly defy characterization.

Ultimately, it seems that this issue boils down to a matter of taste.

This is usually not a problem, so long as this taste is confined to a particular implementation. The problem with R6RS is that it is not just an implementation; it is a standard that can affect all implementations. R6RS, compared to previous revisions, makes a dramatic number of changes to the Scheme standard. Each one, individually, is not such a big problem; it is the entirety of all these changes taken together without sufficient discussion that is the problem.

The members of the board had to vote for all the changes taken together, rather than each one separately. A standard usually should require a consensus; however, this consensus was not really achieved in the case of R6RS (read through the reasoning behind both the “yes” and “no” votes in the “R6RS Ratification Vote,” and you will see the scope of the division).

Some of the main points of this division seem to be the following (apologies to those whose votes are not listed below; I have listed only the votes of names that sounded familiar to me, but there were many other significant votes, which were omitted not because of lack of significance, but because of lack of space and time):

the module system (see votes by Chris Hanson and Taylor R Campbell)

SYNTAX-CASE (see the vote by Chris Hanson above)

the switch to case sensitivity (see the vote by Jonathan Rees)

defining too many features as part of the language, rather than on top of the language (see the vote by Nils M Holm)

lack of time to change the draft to meet the deadline of the ratification draft (see the vote by Shiro Kawai)

too long description of the specification (thrice the previous one); restrictions on implementation design that impede future development of the language in the areas of numbers, text manipulation & Unicode, and the module system; overreach of the module system’s definition (see the vote by Taylor R Campbell)

Even some of the “yes” votes list “imperfections” that “troubled” them:

apparent inflexibility of the library system, and absence of a facility analagous to Common Lisp’s reader macros (see the vote by Alexey Radul)

In sum, it seems that R6RS was at least partly motivated by a perceived need by at least some of the new authors for a standard of Scheme that would help ease the transition between the functional and object-oriented paradigms. Apparently, at least some of the authors perceived that adding more features to the core language, instead of defining a small core language and adding features on top of the language, would help with this transition.

Another problem was lack of time. R6RS seems rather rushed compared to previous specifications. There probably should have been more discussion before finalizing the specification. In particular, there should have been some means of voting on each potential feature separately, instead of on all of them together. It is quite possible for each feature alone to be quite useful, but for the combination of all of them put together suddenly at once to be quite problematic.

(This entry an adaptation of my post “Re: History of Scheme People,” dated “Thu, 26 Feb 2009 15:45:33 +0900,” on the USENET newsgroup comp.lang.scheme.)

Advertisement