My answers to your thirty questions on R^RS

[andy@sun3.ads.ARPA (Andy Cromarty)]

Jonathan,

Here is my list of answers to the specific report-related questions
you posed to the group.  I've only answered the ones I have strong
opinion on.

1. The presence of BEGIN in Scheme is frankly somewhat of an
   embarrasment.  It really should be flushed, but politically
   it's probably too late.  Still, I vote (b).

2. Keep the >? forms.  All predicates should end in ? for
   uniformity.  This kind of consistency is much more important for
   pedagogical purposes than is similarity to CL, Pascal, or any
   other existing language.

4. Substring-move-*: flush.  I think I have simple Scheme definitions
   for these, if anyone needs them once they're flushed.

5. Simply make it clear that evaluation order is unspecified (and
   should not be depended on); to guarantee sequential evaluation 
   of a collection of combinations, use SEQUENCE.

7. Port = port.  Safer that way.

11.  Yes, PROCEDURE?  would be welcome.

12. (if x 1) vs. (cond ((x 1)): I suggest

	(if x 1)			=> 1 iff x, else <unspecified>
	(cond ((x 1)))			=> 1 iff x, else <unspecified>
	(case (not (not x)) ((#t) 1))	=> 1 iff x, else <unspecified>

   This follows the general principle that if you fall off the end
   of a control construct, the results are not guaranteed.  If you
   want a guaranteed return value in your program, you specify one
   using ELSE or the two-armed IF as appropriate; that's what they're
   there for.  This should be phrased to say that ``it is an error''
   to rely on the result of a control construct that returns an
   <unspecified> result.

13.  Flush (define ((((a b) c) d) e) ...) syntax.

14. To me, INCLUDE means "include."  If we want the effect to be
    equivalent to having the loaded text be lexically present,
    INCLUDE is an excellent name, and helps avoid some of the
    concerns people have had about what it means to have a dynamic
    programming environment for a lexically scoped language.  I would,
    however, want to see a resolution to such problems as
	 (IF X (INCLUDE "FOO"))
    If this evaluation depends on the dynamics of the binding
    environment, then "LOAD" is more appropriate.  INCLUDE would
    have to be a non-expression statement, e.g. the above example
    would only be syntactically correct if "FOO" happened to contain
    exactly one or two expressions at the top level of the file, and
    the INCLUDE would always get performed regardless of X's value.

21.  One-based sections.

24.  I guess some people don't like to type and have bad editors, or
    maybe bad pretty-printers.  CALL/CC is scarcely an intuitive
    name; its chief virtue seems to be the number of characters it
    contains.  But it seems to be regionally entrenched; keep it
    "informally optional" to the standard CALL-WITH-CURRENT-CONTINUATION
    if necessary.  (It will not appear in our Scheme implementations.)

26. FORCE and DELAY are new ideas to most readers of the report, at
    least for its SIGPLAN incarnation.  Good pedagogy suggests they
    be put together if possible.

27.  Yes for () in 3.0.2.

30.  I thought the question of immutable objects was lightly treated
    overall.  Rather than remove the reference on p. 14 SS 5.1, I'd
    prefer to see more detail, and perhaps (a) something explicitly
    noting that  set-car!  and set-cdr! are destructors (or
    mutators if you prefer) and (b) the explicit assertion that
    destructors end in ``!'' in Scheme.

------------------------------------------------------------------------
Other topics:

-1+ : I prefer to see this kept, in inessential status.  When I first
    saw it, it struck me as the first time any LISP had gotten this
    right.  It says exactly what it means.  Better no decrement 
    function at all, however, than using "1-" to mean decrement; "1-"
    says exaactly what it *doesn't* mean.

    Since there was a complaint, I might suggest ``minus one plus''
    as the pronunciation for "-1+", as in "minus one plus 3" for 
    (-1+ 3) (or "negative one plus three," if you prefer).  I
    scarcely find SUCC pronounceable in any socially acceptable way,
    and it certainly doesn't seem to me to be a serious alternative.

WHEN: This probably seems like a good idea to people who don't do
    concurrent programming.  When you deal with time in your
    programs, ``when'' already has a confusing enough meaning without
    overloading it to mean IF. For that matter, a couple years from
    now we may want to use WHEN for event management.

S&ICP: I do not know what it means to (as one person admonished)
    ``fix the book''; in particular, I don't know how you recall
    thousands of copies.  Independent of the quality of the
    presentation and choices reflected in S&ICP, which I admit to
    admiring tremendously, I believe that this book has done
    more for Scheme than any other single force in Scheme's history,
    and I believe we should endeavor to support a Scheme compatible
    with it.  Most of my colleages who own the book have it because
    they were interested in obtaining a good book on LISP or a good
    book on programming, and to a person every one with whom I've
    spoken agrees that it is probably the best available for both
    purposes.  Let's not kill the goose that lays our golden eggs.