Grandfathering response

[Dan Friedman <dfried%indiana.csnet@CSNET-RELAY.ARPA>]

1.  BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report;
    it's obvious to the world we couldn't get consensus on this one.
    Many people have told me that they don't care which one is there, so
    long as there's only one.  SEQUENCE was used heavily in S&ICP and
    for that reason I think it should be retained; thus the options I
    offer are
      (a) leave things as they are (BEGIN essential with non-essential
	  synonym SEQUENCE),
      (b) remove BEGIN and make SEQUENCE essential (noting in the Notes
	  section that BEGIN, like #!TRUE etc., should be supported by
	  those implementations which care about running code written in
	  the past year).
    Let me know your vote if you haven't done so already.

*****>>  (a) 
 
2.  Similarly but less glaringly, we have a problem with the numeric
    comparisons.  Again, many people have said they don't care but they only
    want one set, with or without question marks.  Thus I offer
    the choices
      (a) leave things as they are
      (b) flush the alternative names  <? <=? >? >=? =?
    [The ones without question marks were used in S&ICP; moreover, they
    exist in other Lisp dialects.  The argument in favor of the ?'s is that
    it allows the simple statement: "names of predicates end in question mark".]
    Send me your vote.

******>>  (b)

3.  REC and NAMED-LAMBDA :
    Again, I sense capitulation on the part of some who have been stubborn.
    The only options permitted are:
      (a) Keep both
      (b) Flush both
    My editorial sense is that we should be able to achieve (b).  Remember,
    the language also doesn't have EVAL, environments, or macros, so if you
    want to keep these features please say how they're different from other
    "indispensible" features that the language DOESN'T have.

Named-lambda is totally unacceptable.
Letrec is often overkill and without macros we will be left
with using it.  Rec is an incredibly powerful tool.  I'd hate
to lose it from my repertoire.  However, named-lambda is an
ugly so I am forced, given these choices, to opt for (b).
 
4.  SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! :
    Many people have suggested removing these.  Anyone who wants them
    retained MUST provide a convincing rationale, for inclusion in the
    report.  Otherwise I'll remove them.

****>> Remove them
 
5.  Should we say anything about the possibility of parallel or
    interleaved argument evaluation?  Remembering something I thought I
    heard Will once say, I added the innocent little phrase "or perhaps
    in parallel" to the description of procedure calling.  Richard
    Kelsey quickly pointed out that if it's mentioned as being a
    possibly legal implementation, many otherwise valid scheme programs
    may fail to run in implementations which do this, because they won't
    do necessary synchronization.  I agree; this is acceptable only if
    we provide synchronization primitives. 

****>> Yes, either provide synchonization primitives or flush the comment
 
8.  Apparently there's no difference between ABS and MAGNITUDE.  Should we
    keep both?  If so, should I change the presentation in any way?

*****>> don't keep both.
 
9.  ANGLE is what Common Lisp calls PHASE; any interest in changing the
    name? ...

*****>> I agree with the consensus.
 
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)).

*****>> follow Occam's razor here.

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
    this predicate.  After thinking about this further I think it's not such
    a bad idea, even though it is of limited use.  Is anyone opposed to
    having an essential procedure PROCEDURE?, to round out the set of type
    predicates?

*****> include procedure?, but be sure that 
         (call/cc (lambda (k) (k (procedure? k)))) --> #t.

12. (if x 1) vs.  (cond (x 1)) -- this is inconsistent, as a couple of people
    have pointed out.  I would expect these two expressions to have the
    same meaning, but they don't.  The first is defined to always return
    an unspecified value.  The second is defined to return the value 1
    if x is true, and an unspecified value otherwise.  I would like to
    make this consistent, and there are two ways to do.  Take your pick:
      (a) Change IF expressions so that they return the value of the
	  second form if the first form evaluates to false.
      (b) Change COND and CASE so that they return an unspecified value if
	  there is no ELSE clause.
    Here are some arguments in favor of (a):  
     - It removes the possibility of inferring that an implementation might
       not be tail-recursive through an alternate-less IF.
     - Similarly, it makes (IF #T <exp>) mean the same as <exp>, and removes
       doubt about the meaning of things like (if x (if y 1) z).
     - It simplifies the macro expansion of COND as compared with (b).
     - Option (b) is obviously undesirable (consider the case of mutually
       exclusive test expressions in a COND).

****>> I favor including a "(when pred val) as the proper special form
for two branch-if's.  That way two branch-if's would be syntactically
illegal.  I've used them for about a year and I find less bugs creeping
into other's and my own programs.

13. Many people would like to see the (define ((((a b) c) d) e) ...)
    feature go away.  S&ICP doesn't use it, and it has a rather complicated
    syntax (look at the BNF for evidence).  Vote keep or flush.

*****>> flush it.

Presentation questions:

18. Several people have complained about Clinger's perhaps overly accurate
    description of what happens when variables become bound.  To be
    accurate, we have to say that locations are created and the initial
    value is stored in the location, but this doesn't sit well with the
    desire to have Scheme sound like an almost-functional language.
    What to do?

****> Realize that Scheme is not "almost"-functional, it's almost Algol!
      I agree wholeheartedly agree with Will's characterization.
      The best that can be said with respect to the functionality
      of Scheme is that it contains a coherent subset that is "functional".
    
19. What should the dedication be?  Sussman suggested the PDP-6, which was
    the world's first Lisp machine, but some people didn't like this joke.
    I have changed it to Christopher Strachey in the draft.

****> I prefer Christopher Strachey.
    
21. Should section numbers be zero-based?  I'm beginning to think this looks
    unprofessional; and it just doesn't look right in several places.  It
    worked well in the previous version of the report, and it's clearly more
    consistent with the language (which is zero-based), but it doesn't work
    the way I've reorganized things.  If you like zero-based section
    numbers, speak up.

*****> 1-based seems better.
    
22. Was Scheme the first programming language to have first-class lexical
    closures?  Can we say anything edifying along these lines?

*****> Landin's ISWIM was the first well-known one back in the early 60's.
       However, I would guess that the use of "function" in the
       "Lisp 1.5 Programmming Language Manual" should count as
       a first-class closure.  If all "lambda"'s were surrounded by
       (function ...) then LISP 1.5 would model them. Furthermore,
       call/cc can be written with Landin's J operat.
    
23. I flushed the historical note "CATCH could be provided by a procedure"
    sentence (again, because two or three people thought it was random and I
    agreed), but some of you have complained about this.  Why should this
    bit of history be present, but not others that are at least as
    important?  

*****> I won't argue for the history.  However, the implementor who
       thinks that catch (as in Common Lisp) and call/cc are the same
       is in for a shock.  That should perhaps be pointed out.
    
24. CALL/CC was mentioned in a sentence in a rationale in the RRRS.  I
    flushed the reference because (a) a number of people find the name
    CALL/CC quite distasteful and (b) it is inconsistent to mention here
    that some scheme implementations provide an alternate name for this but
    not also do so for LABELS, BLOCK, and a zillion other things.

****> Carolyn Talcott in her dissertation suggested the term "note".
      I could live with that.  If call-with-current-continuation is
      the only term, this will make those of us who write about this object
      uncomfortable. I think we agreed that "call/cc" would be an 
      acceptable abbreviation and I would prefer to keep that name
      in the report.  Those who don't like the name can choose not to use it.
      In a sense I agree with your argument, but "call-with-current
      -continuation has 30 characters in it!, "labels" and "letrec", and
      "block" and "begin" each have the same number of characters.

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.

****> "variable" is a "dangerous" word, try to expunge it.  Opinions differ
    as to what a variable is.
    
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.

****> I favor join them.  I don't much care where they are joined.
    
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?

****> See comment on 26.
    
29. There are two nonterminals in the BNF that need names.  Currently they
    are called <formals> and <formalz> which was never intended to be a
    serious suggestion (I put it there to see if anyone would actually read
    the BNF!).  Actually one or both of these can go away if NAMED-LAMBDA
    and/or (DEFINE ((( ...) ...) ...) ...) go away.  Can someone who likes
    these things take a look at the BNF and suggest names for these?

****> I hope they go away.

Language:

Removed non-essential features from examples (including the big one)
where possible:  (1+ x) --> (+ x 1), (-1+ x) --> (- x 1), (define (foo
...) ...) --> (define foo (lambda ...)), 1-armed if --> cond, named let
--> letrec.

****> I'd still prefer "add1" or "succ" and "sub1" or "pred" to the
abuse of punnery "-1+", and its slightly weaker sibling "1+".
The cuteness of "-1+" should go.  In writing for a mass audience
I have learned that there is a time and a place for clever un-pronouceable
function names.  Please remove them and find pronounceable words