variata

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

I am absolutely opposed to making (COND) or (COND (ELSE)) or (BEGIN) or 
(LAMBDA ()) illegal. I am content to make them return undefined values but 
I insist that, for example, (LAMBDA () (BEGIN) 3) is a completely well-formed
expression that should neither cause the compiler to say anything nor cause 
an error at runtime.

I am very opposed to requiring ELSE to be the last clause in a COND. It seems 
to me that
 (COND ((FOO)) (ELSE #T) ((BAR)))
is like like
 (OR (FOO) #T (BAR)).
I hope no one is going to insist that the previous form should also be illegal
and/or that it should be warned about by a compiler. The call to BAR is 
obviously not going to get reached for pragmatic reasons, but there may be
legitimate situations where program-writing programs could want to construct 
something like this and I think we'd be shooting ourselves in the foot to 
disallow such things. Also, I think it tends to make the grammar look more 
graceful if ELSE can occur anyway. The particular case of interest is:
  `(COND ,@FORMS (ELSE FOO))
where FORMS may be allowed to contain an ELSE clause. I object to having to
write:
  `(COND ,@FORMS ,@(IF (AND FORMS (NOT (EQ (CAR (LAST FORMS)) 'ELSE)))
		       `((ELSE FOO))
		       `()))

If you decide to make any of the above forms legal, I wish to have my 
reasons for disagreement cited.

I think CASE should be changed to use EQUAL?, which I think is in agreement
with a recent suggestion by you. This will get around a lot of confusion that
could otherwise result from the recent trend toward wanting to intern quoted
structure.

I'm fairly satisfied with the way things seem to be going in the EQ? and 
EQV? discussion so will mostly decline from any comment for now on that 
subject.

    JAR: If people believe that it's important to be able to parse Scheme's 
    read syntax using only standard Common Lisp reader features, then by all
    means we must allow (eq? '#() '#()) to be false, but we also have to
    change the syntax of numbers, and make colon not be a constituent
    character.  But Scheme's eqv? could still deal with #() and "" as I
    propose even if eq? doesn't.
    
Right.

    JAR: It looks like I'll lose on this point, so I won't push it too hard.  
    I'm    just resisting adding yet another clause which basically says "we 
    did this for compatibility with Common Lisp."

I am sympathetic to this position.

I strongly oppose requiring APPEND to do gratuitous copying. It's trivial to
adopt 

    Bartley (about APPEND): ... I'd like some discussion on this.  It sounds 
    like something a LISP programmer could trip up on, especially those 
    who use (APPEND X '()) to copy X.  Steele's book specifically mentions
    that APPEND will work that way in Common LISP, but implies that it is 
    poor style.  My inclination is to be compatible with Common LISP in 
    order to minimize frustration for the poor people we're trying to 
    win over to Scheme.

    JAR: If this is what other people want I'm happy with it too (except 
    again for the fact that I'll have to insert another apology and another 
    reference to Common Lisp).

The fact that CL provides COPY-LIST is enough for me. I am strongly opposed
to continuing this lossage of forcing APPEND to do gratuitous copying. You're
falling down on your let's-not-be-gratuitously-compatible-with-CL maxim. CL
itself is really only doing it for compatibility, too. This is a case where
we're clearly right and ought not give in.

    JAR: What about (let ((x (list 'a))) (eq? x (reverse x))) ?

    Bartley: I feel strongly that REVERSE should always copy (unless its 
    argument is the empty list), since it is easier to remember that rule 
    than that it does so only when there's more than one element in the list.
    Pragmatically, I often do something like (APPEND! (REVERSE X) Y), and
    wouldn't want to side effect the original list in X if it had exactly
    one element.  (Note that this works correctly when X is the empty
    list, so this is a pretty unusual boundary condition.)

    JAR: I agree.  (Except note that it doesn't copy empty lists....)

I am receptive to the idea of permitting the result of REVERSE to share with
its input. The idiom (APPEND! (REVERSE X) Y) should just be named. CL has 
REVAPPEND and NRECONC. I believe we should just have APPEND-REVERSE and 
APPEND-REVERSE! which do these common operations. This would reduce the need 
to rely on  copying. I think we should take a consistent stand on the idea 
that REVERSE, APPEND, do not have to copy and that that's why we provide 
COPY-LIST. People can always write their own COPY-LIST-REVERSE, 
COPY-LIST-APPEND, etc. if they really need to intertwine the two operations 
for some efficiency reason. The dumb routines are so easy to write yourself, 
after all. The ones provided by the system should be the messy-to-write 
super-optimizing ones.