Skip to content

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

February 26, 2009

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 (R6RS) 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.)

About these ads
9 Comments
  1. Robby Findler permalink

    This post reflects a fairly shallow understanding of R6RS and how decisions were made and the conclusions are just plain wrong. (For example, I had no hand in any of the decisions about what does into the language. Neither did Jacob Matthews.)

    I encourage you to actually read the editor’s comments on why decisions were made instead of just guessing at them. There is a large body of messages that were made public that give you their rationales for various features.

  2. While I can understand how an outsider may come to the conclusions that you are posting here, they truly do miss the point — completely. The idea of OO/Imperative programming is nothing that anybody in the Scheme community objects to. Scheme *is* derived from a model of Actors, which is a model of OO programming, and deep down it is therefore an OO language. (See my Ecoop keynote for some more insight.)

    The true point of contention is the degree of dynamics that Scheme implementations should provide, as in dynamic typing, dynamic loading of code, dynamic repl, etc. In addition, the user community fails to agree on whether they want a useful language — with batteries included — or a small idealistic language that anyone who reads EOPL or PLAI can implement in a day (mostly) in his favorite language. The rest is about personalities — old generations of Schemers of a by-gone era — and those who have maintained, expanded, and moved Scheme forward over the past 10 years.

    – Matthias

    • Matthias Felleisen,

      Thank you for your comment; for some reason, it had been auto-sorted into the Spam category, from which I just rescued it.

      This is the first time that I have heard of Scheme described as an “OO language”; I had always thought of it as a functional language (although I’m sure that Shriram Krishnamurthi would claim that the paradigm doesn’t matter, because according to him, languages are just “melanges” of features).

      Let me read through your Ecoop keynote, then. Do you mean your presentation entitled “Functional Objects?”

  3. Hi Ben,

    If you read the emails for the past month on the R6RS mailing list you will get a snapshot of “what happened”. It didn’t have anything to do with how certain educators felt about where Scheme fits in the educational process.

  4. Robby Findler and Grant Rettke,

    In reference to the messages that you reference, I tried to get access to the R6RS mailing list archives, but it seems that at least posts after June 2007 belonging to those archives are private and password-protected. Further, the mailing list itself is a closed list, and it seems that the list is open only to editors of the draft (see the post by Marc Feeley entitled “[R6RS] Mailing list,” dated “Mon Jan 19 17:12:28 EST 2004,” on that list); viz.:

    Michael Sperber wrote:

    > >>>>> “Marc” == Marc Feeley writes:
    >
    > Marc> At this point, only the editors can post to the list and read the
    > Marc> archive. When our job is done and R6RS is finalized I think the
    > Marc> archive should become public

    If the list was to become public and isn’t yet public, then probably still “only the editors can post to the list and read the archive.” I’m not an editor.

    The archives that were available via a separate route (not from the above-mentioned mailing list information page) only extend to June 2007.

    Given the above, how do I “read the e-mails for the past month on the R6RS mailing list?”

  5. Grant Rettke permalink

    Hi Ben,

    On the R6RS discussion mailing list; the editors and other folks have been discussing the “R6RS problem” and its history. It is from those emails that I have pieced together, roughly, “what happened”. This is not ideal; but I don’t know where to look to get the real details. It doesn’t look like Robby and I are referring to the same thing.

    Here is what I mean:

    http://lists.r6rs.org/pipermail/r6rs-discuss/

    • Hi Grant Rettke,

      Interesting … I was not aware that the list that you referenced described “what happened”; I had merely tried to read the R6RS mailing list, and upon discovering that it was a closed list, tried to piece together my own idea of what had happened.

      I shall read the r6rs-discuss mailing list that you mentioned and try to write a revised follow-up blog entry as soon as I have a better idea of what happened. There are quite a few messages there; reading them all may take between a few days to a couple weeks.

      Thank you for the information!

  6. schillingklaus permalink

    I gave up on scheme because of r5ns and am moving on to newLisp because it provides a lot more dynamicity.

Trackbacks & Pingbacks

  1. A Correction to “Too Much is Not Enough: The Revised^6 Report on the Algorithmic Language Scheme (R6RS)” « Monadically Speaking: Benjamin’s Adventures in PLT Wonderland

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: