[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: rrrs-authors
- Subject: re: tail-recursion
- From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
- Date: 26 Apr 90 1355 PDT
[In reply to message from email@example.com sent Wed, 25 Apr 90 16:37:45 CDT.]
The creation of a standard language is done because there is a perceived
need to unify a community, and often to satisfy commercial needs. Once the
step is taken to start a standardization process, one needs to consider
the ramifications of operating in the real world.
One group I am trying to influence is a compiler backend group that is
doing a backend to support all languages at a very large computer company
that has never had a common backend before. This group, which is fairly
small, has monthly milestones laid out in front of from now until
mid-1992. They will support every language you can think of except
SmallTalk and PROLOG, and the machine architectures they will target are
challenging, to say the least.
Now, how do you propose that I persuade them to put in an optimization for
Scheme? How do I convince them that the compiler switches needed to turn
this off for debugging in other languages is worth their effort? Should I
count up the 10000 Scheme programmers for them, noting that nearly all of
them are in universities and are generally just playing around?
No, among other things, I try to convince them that Scheme would make an
excellent extension language, and that several groups at their company
have need for one (I also argue that it is a good optimization for other
languages). Now, when they come back and tell me that extension languages
are mostly for extending command languages and that lengthy iterations are
not common or never done, and that the extension language groups should
just add a simple iterative construct for that, how am I to argue against
Couple this with the fact that Scheme is a standard language, which is a
drawing point for the various extension language groups, and with the fact
that the language definition does not let them call their implementation a
conforming implementation. Note that other languages have various levels
of conformance, so this is not such an outrageous thing.
I could persuade them more effectively if I could point to a larger
programmer community, which I could do if I could get some variety of
Scheme into the mainstream, which I could do if I could only get the
definers of the language to allow a mainstream implementation to be called
If you wanted to keep your language to yourselves, you shouldn't have
opened up the gates of standardization, which has severe backpressure on
the R...RS language. (By the way, I argued against standarization of
Someone conjectured that if we `cave in' on tail call removal, we will
never get these outsiders to adopt it, because, hey, they won their
argument. Well, I cannot think of gentle enough words to use to educate
this someone that the real world of negotiation is not like a trivial war
board game. Once agreements are made in such a way that you can establish
technical collegiality, additional compromises can be made which will
enable complete implementations.
Someone else said this:
``Please stop trying to require Scheme to be Common Lisp compatible.
Instead, phrase your proposals in terms of ``Let's allow Level 0
implementations to be deficient in the following ways...'' ''
Fortunately, this person was not referring to me, because my proposals had
always been of the form of allowing for deficient implementatations along
specified dimensions (I possibly am making the mistake of assuming that if
two sentences appear adjacently in the same paragraph, they are related).
(As I understand, almost all Scheme implementations are horribly deficient
anyway because they use intrusive GC techniques, and the ones that support
generation scavenging type techniques are slightly deficient because they
aren't incremental or real time. Also, most don't support the full range
of available compiler optimizations, and maybe only one does automatic
fine-grained parallelism detection, and maybe none of them have
floating-point computation competitive with FORTRAN.)
The first sentence of the quote, though, makes me wonder whom we think is
the enemy, and why we think there is one. I have been associated with the
Scheme community since 1976, when my friends Sussman and Steele started
writing their papers outlining Scheme. I have been associated with the
Common Lisp community since it started, and I helped start it. I feel no
oddness in programming in either one depending on what I am doing. I feel
no strangeness that I do my commercial work with CL and my research work
with an extended Scheme. I do not find myself ill and distorted because of
the two computers I have access to at home, one has CL and the other
Scheme. I have a lengthy list of critiques of CL, and an equally lengthy
one of Scheme.
The outside world feels that Scheme and Lisp are nearly the same language,
only one is a lot bigger than the other. The majority of the CL community
has great respect for the Scheme community. Do you not have that same
respect for them? The members of the CL community are returing from the
forest with the arrows of commercial battle in their backs; possibly we
should try to learn what happened to them so as to not make the same
One big mistake is to think that some other language is an enemy. We at
the CL companies once thought that there was a C versus Lisp battle. No
such thing ever happened. It was a matter of defining requirements for
Lisp being in the mainstream and meeting those requirements. Similarly,
there is no such thing as a Common Lisp versus Scheme battle. If someone
who operates in the Common Lisp world makes a suggestion, it is usually
for reasons other than wishing Scheme to become more Common-Lisp-like.
Besides, who mentioned CL in the first place? Not me.
Oh, by the way, I convinced that compiler backend group to put in tail
call removal. I did it by pointing out that the CL my company supplies to
them will need to use their backends in 1992, and that for my
implementation to work well, tail call removal needs to be supported by
the compiler. One down, 10 to go.