History of Scheme People
j85wilson
A thought occurred to me while reading the r6rs-discuss list. I know
some (although surely not enough) of the history of Scheme itself, but
almost none of the history of the people who have created, shaped, and
used Scheme. If anyone cared to share some stories, it would be much
appreciated. Perhaps eventually we can collect some of these and post
them somewhere as a sample of our collective history, something very
important to keep and to know.
Regards,
Jon
Benjamin L. Russell
You may find the following history of the T dialect of the Scheme
programming language interesting:
Olin Shivers: History of T
http://www.paulgraham.com/thist.html
In addition, see the following thread, started by "shivers" (possibly
Olin Shivers himself):
T
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg00650.html
You can see the entire thread on the following page:
ll1-d...@ai.mit.edu list archive, by thread.
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/threads.html#00650
In addition, there is a post by Taylor Campbell at MIT-Scheme-users,
dated "Sat, 19 Feb 2005 12:40:08 -0800," about a "T Revival Project":
>As you might
>know, I & Brian Mastenbrook started what we're calling the T Revival
>Project....
IIRC, I used to use T in college, and very much wished to see a
revival, but apparently Campbell's idea generated too much publicity,
and he took down his own T Revival Project page (see
http://mumble.net/~campbell/t/t.html):
>Nothing to see here. Please move along. Publicity was not the intent of the
>page that is not here. If you wish to contact the author of this document about
>T, please find his email address elsewhere; if you cannot find his email address,
>then your inquiry must not have been very important to begin with.
I actually did find his e-mail address elsewhere through some diligent
research, and sent him a message asking him about the project, but he
never responded. Apparently, he wasn't being very truthful about the
"please find his email address elsewhere" part; in that case, he
should actually have written "please DON'T find his email address
elsewhere."
T is special as a dialect of Scheme because it had some features
missing from modern dialects of Scheme. According to the following
Wikipedia entry for T:
"T (programming language) - Wikipedia, the free encyclopedia"
http://en.wikipedia.org/wiki/T_(programming_language)
>T contains some features that modern Scheme does not have. For example, T is
>object-oriented, and it has first-class environments, called locales, which can be
>modified non-locally and used as a module system. T has several extra special forms
>for lazy evaluation and flow control, as well as an equivalent to Common Lisp's setf. T,
>like Scheme, supports call-with-current-continuation, but it also has a more limited form
>called catch.
Frankly, I'm quite frustrated about the lack of any information about
the T Revival Project. I went to the same college where T originated,
and would like to work with an implementation of T if possible, if
only for nostalgic reasons.
If anybody knows anything about either the T Revival Project, or a
downloadable version of T, please let me know.
-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
Benjamin L. Russell
<DekuDe...@Yahoo.com> wrote:
>In addition, there is a post by Taylor Campbell at MIT-Scheme-users,
>dated "Sat, 19 Feb 2005 12:40:08 -0800," about a "T Revival Project":
>
>>As you might
>>know, I & Brian Mastenbrook started what we're calling the T Revival
>>Project....
Apparently, I had forgotten to include the following link for the
above reference mentioning the "T Revival Project":
Re: [MIT-Scheme-users] MIT/GNU Scheme status
http://www.mail-archive.com/mit-sche...@gnu.org/msg00000.html
The relevant paragraph is the last one, as follows:
>I'm very interested in helping out -- in general, I'm interested in
>seeing the two old & really industrial-strength Scheme systems, MIT
>Scheme & T, brought up to date & into active development. As you might
>know, I & Brian Mastenbrook started what we're calling the T Revival
>Project, and I'm interested in helping out with MIT Scheme, too.
Incidentally, according to the previous quoted paragraph by Chris
Hanson in the post, MIT/GNU Scheme was relatively inactive as well:
>On Tue, 25 Jan 2005, Chris Hanson wrote:
>[...]
>
>> To summarize, MIT/GNU Scheme is _not_ dead, but it's awfully sleepy.
>> I will continue to support it for the foreseeable future, but due to
>> lack of interest I don't want to make large infrastructural changes.
>> I _am_ willing to support such efforts by others, however. I will
>> continue to make releases as time permits, but if you want to see more
>> activity, you'll have to help out. So drop me a line if you're
>> interested.
Actually, it seems that MIT/GNU Scheme is still relatively inactive. I
also read the MIT-Scheme-devel mailing list (see
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel), but currently
that mailing list only gets an average of about 1-3 posts per month.
Considering that MIT/GNU Scheme is the primary implementation used in
SICP, it seems a pity that the implementation does not gather more
users. Both MIT Scheme and T had important roles in the history and
development of Scheme; I would really wish to continue using the
former, and if possible resume using the latter as well.
Grant Rettke
> A thought occurred to me while reading the r6rs-discuss list. I know
> some (although surely not enough) of the history of Scheme itself, but
> almost none of the history of the people who have created, shaped, and
> used Scheme.
I wondered that myself. I started here:
http://www.wisdomandwonder.com/article/1927/a-scheme-timeline
Grant Rettke
> >> I will continue to support it for the foreseeable future, but due to
> >> lack of interest I don't want to make large infrastructural changes.
> >> I _am_ willing to support such efforts by others, however. I will
> >> continue to make releases as time permits, but if you want to see more
> >> activity, you'll have to help out. So drop me a line if you're
> >> interested.
>
> Actually, it seems that MIT/GNU Scheme is still relatively inactive.
On the R6RS everyone is surprised that people think that MIT/GNU
Scheme is dead.
leppie
> I wondered that myself. I started here:
>
> http://www.wisdomandwonder.com/article/1927/a-scheme-timeline
Cool!
How about adding implementations too?
Grant Rettke
> How about adding implementations too?
That would be interesting, but I feel like adding more information
would require a better tool than Graphviz, and I don't know what that
it yet.
Benjamin L. Russell
<gre...@gmail.com> wrote:
>On Feb 24, 8:39?pm, j85wilson <j85wil...@fastmail.fm> wrote:
>> A thought occurred to me while reading the r6rs-discuss list. ?I know
>> some (although surely not enough) of the history of Scheme itself, but
>> almost none of the history of the people who have created, shaped, and
>> used Scheme.
>
>I wondered that myself. I started here:
>
>http://www.wisdomandwonder.com/article/1927/a-scheme-timeline
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 follows is a rather long and possibly controversial discussion
of the possible reasons for this division of authors between R2RS -
R5RS, and R6RS; please read only if you don't mind reading a long
discussion; otherwise, just skip the rest of this message, please. My
aim is to try to analyze and understand what happened between R5RS and
R6RS, and why.)
<monologue>
What happened to all the previous authors, and who are these new
authors?
Well, 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" (see
http://www.ccs.neu.edu/scheme/pubs/jfp2004-fffk.pdf). 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" at
http://www.haskell.org/pipermail/haskell-cafe/2007-August/030178.html):
>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"
at
http://list.cs.brown.edu/pipermail/plt-scheme/2008-August/026424.html):
>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" at
http://www.cs.brown.edu/~sk/Publications/Papers/Published/sk-teach-pl-post-linnaean/paper.pdf),
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" at
http://www.r6rs.org/ratification/results.html, 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
(http://www.r6rs.org/ratification/results.html#X78) and Taylor
Campbell (http://www.r6rs.org/ratification/results.html#X100))
SYNTAX-CASE (see the vote by Chris Hanson above)
the switch to case sensitivity (see the vote by Jonathan Rees
(http://www.r6rs.org/ratification/results.html#X91))
defining too many features as part of the language, rather than on top
of the language (see the vote by Nils M Holm
(http://www.r6rs.org/ratification/results.html#X94))
lack of time to change the draft to meet the deadline of the
ratification draft (see the vote by Shiro Kawai
(http://www.r6rs.org/ratification/results.html#X99))
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
(http://www.r6rs.org/ratification/results.html#X100))
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 (http://www.r6rs.org/ratification/results.html#X2))
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.
</monologue>
namekuseijin
wrote:
> On Wed, 25 Feb 2009 07:05:41 -0800 (PST), Grant Rettke
> 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
William D. Clinger is still in frantic Scheme activity, and although
he didn't endorse R6RS his Larceny implementation supports the latest
standard.
Jens Axel Soegaard
> 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
From the front page of R6RS:
ROBERT BRUCE FINDLER, JACOB MATTHEWS
(Authors, formal semantics)
That is, they wrote the section on the formal semantics.
So if you are comparing to earlier reports you need to leave them out.
--
Jens Axel S?gaard