variata

[Bill Rozas <JINX%OZ.AI.MIT.EDU@xx.lcs.mit.edu>]

    To summarize:

     -- We agree that (ELSE) is a no-no and that (COND) and (COND (ELSE exp))
     are valid.

     -- I feel that (BEGIN) should have the same meaning as (COND), but I
    won't push the point.

I don't like this.  Unfortunately JAR did not give me choice c (status
quo, where (COND (ELSE ...)) is legal, but (COND) is not), which I
like best.  I object pretty strongly to (BEGIN) and somewhat less
strongly to (COND).  The usual rationale is that it makes macros
easier to write, but this is just laziness of the same sort as using
(cdr (assq <something> <some-list>)) in a Lisp where (cdr '()) -> '().
(COND (ELSE ...)) although silly has a clear meaning (unless the ELSE
clause is empty, which should be an error, but we agree on this).

     -- We agree on using EQV? for CASE.

I like JAR's proposal too.

     -- We agree that (EQV? "" "") and (EQV? #() #()) are true, but I worry
    about confusion when I mix Scheme and Common LISP programs.

I'm worried about gratuitous differences between EQ? and EQV?.  I
would object (although not terribly strongly) to making 
(eq? '#() '#()) be #T, but I think it is silly to have EQ? and EQV?
behave differently on this.  The reason I object to (eq? '#() '#())
being #T is that inline coding of make-vector would become more
expensive.  Make-vector is very cheap in our implementation and a good
candidate for inline coding (although we don't currently do it), and
having it intern 0 length vectors (strings) would make it more
expensive.

     -- I like warning messages for things like (MAKE-VECTOR 0 exp) more
    than you do.  We can probably agree to provide declarations so you
    won't refuse to buy my system!

I agree with JAR.  I think that (MAKE-VECTOR 0 exp) is reasonable and
no error (warning) message should be given.  I don't understand why
you object to it.  Why not warn about reversing a list with less than 2
elements also?

     -- I'm not apologetic about trying to avoid ``gratuitous''
    differences with Common LISP, but I don't want to burden the
    description of Scheme with constant references to it either.

I agree.  Unless there is strong reason to do otherwise, we should not
differ from Common Lisp.  This should probably be stated early (if we
all agree, of course), and assumed afterwards.  A reference to this
remark in various places might be appropriate.