Compatibility With Maclisp

[FEINBERG at CMU-20C]

Howdy!
	I agree with you, we must have a consistent policy concerning
maintaining compatibility with Maclisp.  I propose that Common Lisp
learn from the mistakes of Maclisp, not repeat them.  This policy
means that Common Lisp is free to use clear and meaningful names for
its functions, even if they conflict with Maclisp function names.
Yes, some names must be kept for historical purposes (CAR, CDR and
CONS to name a few), but my view of Common Lisp is that it is in fact
a new language, and should not be constrained to live in the #+MACLISP
world.  I think if Common Lisp software becomes useful enough, PDP-10
people will either make a Common Lisp implementation, they will make a
mechanical translator, or they will retrofit Maclisp to run Common
Lisp.  Common Lisp should either be upward compatible Maclisp or
compatibility should take a back seat to a good language.  I think
Common Lisp has justifiably moved far enough away from Maclisp that
the former can no longer be accomplished, so the latter is the only
reasonable choice.  Being half upward compatible only creates more
confusion.