Re: Remaining questions & remarks (2)

[Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>]

   1.  BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report;
       ...
         (a) leave things as they are (BEGIN essential with non-essential
   	  ...
         (b) remove BEGIN and make SEQUENCE essential (noting in the Notes
   	  ...

(b) [I hate the name begin... I am always looking for a corresponding end]

   2.  Similarly but less glaringly, we have a problem with the numeric
       ...
         (a) leave things as they are
         (b) flush the alternative names  <? <=? >? >=? =?
       ...

(b)

   3.  REC and NAMED-LAMBDA :
       Again, I sense capitulation on the part of some who have been stubborn.
       ...
         (a) Keep both
         (b) Flush both
       My editorial sense is that we should be able to achieve (b).  Remember,
       ...

(b)
    
   4.  SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! :
       Many people have suggested removing these.  Anyone who wants them
       ...

remove them
    
   5.  Should we say anything about the possibility of parallel or
       ...

remove mention of parallel argument evaluation
    
   7.  Must a port still be a port (i.e. answer true to INPUT-PORT? or OUTPUT-PORT?)
       ...

I would prefer if it was but not strongly

   9.  ANGLE is what Common Lisp calls PHASE; any interest in changing the
       name? ...

call it phase
    
   10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect
       can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)).  Do we
       apply Occam's razor and remove it?  If it's retained, then I'll just
       document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)).

are they not different in implementations without complex numbers?

   11. JINX says: if PROCEDURE? exists, then a portable printer can be written.
       JAR replies (in jest):
         (define procedure?
   	(lambda (obj)
   	  (not (or (pair? obj) (null? obj) (symbol? obj) (number? obj) ...))))
       Seriously however, I was the only holdout at Brandeis against having
       ...

it should be included---I would much prefer the name "closure?"

   12. (if x 1) vs.  (cond (x 1)) -- this is inconsistent, as a couple of people
       ...
         (a) Change IF expressions so that they return the value of the
   	  ...
         (b) Change COND and CASE so that they return an unspecified value if
   	  ...
       ...

(c) require if to have a consequent and include WHEN as required---this gets
    rid of the whole mess and is much cleaner.
   
   13. Many people would like to see the (define ((((a b) c) d) e) ...)
       ...

flush it
   
   14. Status of LOAD not resolved.  If, as I suggested, LOAD is only
       ...
       renamed to be INCLUDE ?

no... load implies run time, include implies compile time, if they are
different

   15. Page breaks and tabs are mentioned in the report (actually I guess I
       ...

leave them out where possible

   17. Bartley says: "the second sentence of the description of EQUAL? should
       ...

I agree with David
   
   Presentation questions:
   
   18. Several people have complained about Clinger's perhaps overly accurate
       ...

I'd say leave Will's description.
       
   19. What should the dedication be?  Sussman suggested the PDP-6, which was
       ...

how about Haskell B. Curry?

   20. Is it OK to replace "Lazy ML" with "SASL" (last paragraph of section
       ...

it does seem more appropriate; SASL predates lazy ML.

   21. Should section numbers be zero-based?  I'm beginning to think this looks
       ...

1-based seems best

   22. Was Scheme the first programming language to have first-class lexical
       closures?  Can we say anything edifying along these lines?

ISWIM (Burge) had them about ten years prior to Scheme.  might want to refer
to Burge, W.H. ``ISWIM Programming Manual,'' IBM Research Report RA129,
Yorktown Heights, New York (November 1981).

   23. I flushed the historical note "CATCH could be provided by a procedure"
       ...
       
I agree, flush it.

   24. CALL/CC was mentioned in a sentence in a rationale in the RRRS.  I
       ...

definitely keep call/cc.  call/cc has appeared in several papers, and it is
much easier to type in without making mistakes---the other name compromises
did not end us up with names 5 times as long

   25. How best to resolve the inconsistencies between terminology in text and
       semantics?  Namely: "I", "Ide", "identifier" in semantics vs. "variable"
       in text; "Com", "command" in semantics vs. "statement" in text.

I prefer identifier for all symbols, such as keywords and lexical identifiers,
and variable for lexical identifiers.

   26. FORCE & DELAY are still problematic.  About half of respondents said it
       was better to put FORCE up front with DELAY, and the other half thought
       it was fine as it was.  No one gave convincing arguments.

they should be together, I would say where FORCE now is
       
   27. Is 3.0.2 (description of procedure calls) a good place to take note that
       () is not a valid procedure call?

it should be obvious from the syntax

   28. In section 0.0, 2nd paragraph, before the terms "variable" and
       "identifier" have been defined, it should say "variable" instead of
       "identifier" to be consistent with the rest of the report.  Is that OK?

yes

   Changed variable name "loop" to "recur" in the
   call-with-current-continuation example.

please don't---recur is the name of a special form in Chez Scheme and
is used by lots of people---I'd like to avoid confusion

As for grandfathering, unless the original RRRS report was distributed
much more widely than I figure it was, I would rather see no mention of
the incompatibilities.  It is not worthwhile to support old features
when the affected group of people is fairly small (particularly for new
implementations).  Besides, the various language manuals for existing
implementations with all their differing syntaxes were much more widely
distributed in total, and their features are not being grandfathered.

Kent