My comments on the R^RS

[Guy Steele <gls@Think.COM>]

    Date: Thu, 10 Jul 86 12:39:26 PDT
    From: andy@sun3.ads.ARPA (Andy Cromarty)

    Jonathan,

    I've enclosed my comments on the R^3RS in this note
    separately from my answers to your specific questions you asked.
    Hope this helps.  By the way, I know that putting this all together
    involves a lot of work (and sometimes a lot of refereeing), and you
    should be aware that your contribution isn't going unappreciated.   Thanks
    for all the hard work you're putting in, and my apologies in advance
    if I err here due to an insufficiently detailed reading of the report.

Hear, hear!

    ...
    2. As you might expect, I would like to see a somewhat more vigilant
       attitude in warding off the dark forces of Common Lisp.  It is not
       compatibilities or incompatibilities that are gratuitous; it is
       the very act of being concerned with compatibility at all that is
       gratuitous.  We should have our own standards of what a good LISP
       looks like and stick to them.  The first job of a good language is
       to be a good language, not to be just like another bad language
       that's familiar (nor even just like another good language that's
       familiar).  Common Lisp's goals were nearly the opposite of
       Scheme's, and however good a job the CL committee did, we owe them
       no homage.  I recognize that this is more an issue of the design
       of Scheme than of its documentation in a report, but there seems
       to me to be entirely too much concern for similarities and
       dissimilarities w.r.t. Common Lisp in the report.  It may be
       appropriate to discuss the topic of Scheme vs. CL briefly in the
       historical section, but there should be a very clear message to the
       reader that CL followed Scheme -- and continues to, in the sense
       that Scheme is meant to be a progressive attempt at (LISP) language
       design rather than a codification and standardization of existing
       ideas in prior LISPs.   The CL people should be writing reports
       that compare their work to ours, not the other way around.   ``Let
       them eat cake.''  [OK, flame off.]

[a] I think that many papers on Common Lisp have correctly attributed its
debt to Scheme.

[b] I disagree that concern with compatibility is gratuitous.  Perhaps that
concern should be subordinate to other concerns, but when everything else is
truly equal then compatibility is a reasonable criterion for breaking ties.
This is because it is better to be able to tie a feature to something already
familiar than to make a user learn something new.

[c] There should be a very clear message to the reader that Scheme certainly
does owe debts to other sources, and one of them is Common Lisp.  While
Scheme certainly has been the pioneer in the treatment of closures and
functional programming in a Lisp framework, I think it is fair to say that
Common lisp pioneered a rational (forgive the pun) treatment of numeric data
types in a Lisp framework, and my impression is that Scheme learned
something in this area from the Common Lisp experience.

[d] Don't forget that there are some people who worked on both Scheme and
Common Lisp at the same time (I do not count myself as one, by the way), to
whom I am grateful because they learned certain lessons in both contexts at
once and served to transfer ideas in both directions.

    12. I cannot refrain from observing that DO is truly ugly, a
	veritable pig of a construct, and we could have done better.
	We are indeed fortunate that its use under practical circumstances
	is rarely necessary.

I strongly disagree.  DO is a construct that emphasizes the notion that
an iteration can proceed by initializing some state variables and then
repeatedly transforming them while maintaining some invariant until
a condition is reached.  In particular, it emphasizes the fact that
outputs of the iteration as well as inputs can and should be expressed
as iterator-controlled variables.  This is a lesson that the "algebraic"
languages ought to learn.  It is an abomination to see
    sum = 0
    do i = 1 to 10 by 1
      sum = sum + a(i)
    end do
instead of
    do i = 1 to 10 by 1; sum = 0 by a(i); result sum od

    23. NOTES, p.35ff.: This material should stay somehow.  We need to
	make it clear that R^3 Scheme is not being touted as Yet Another
	Ultimate Solution To The Programming Language Problem, but rather
	as a snapshot of a *process* of good design, for which not all
	answers have yet been found.  We also ought to use the opportunity
	for publicity afforded us by SIGPLAN to advertise some of the thorny
	unsolved problems that need further research, and encourage
	language designers to work on them.

Yes.


--Guy