Deprication, cleanup goals, performance

[masinter.pa@Xerox.COM]

I'd like to separate the strategy for dealing with the incompatible changes
 from the changes themselves. We have made other minor and major
incompatible changes to Common Lisp and will probably make more before
we're done. We need a general way of dealing with features that are omitted
and incompatible changes, and the steps you've outlined are reasonable.

Maybe I've said this before, but  I think as far as cleanup is concerned
our major question is: does this make the language enough "better" to be
worth the cost. "Better" is not evaluated in isolation: while "cleaner" and
"easier to understand"  are good properties of a programming language, a
language is also "better" if there already exist a lot of programs written
in it, if there already exist textbooks that teach it. 

If we make too many changes to the point where old programs can no longer
be made to work or if the old textbooks no longer apply. 

Each of us may have different way of combining these orthogonal goals of
"better": folks differ on the importance of compatibility with existing
programs, on the value of simplicity over power and expressiveness.

In the specific case of TEST-NOT-IF-NOT, I think that it makes the language
enough better along the dimensions of cleanliness, and has little impact on
backward compatibility.

One aspect of "better" that seems to be of concern to the community yet we
don't address in the cleanup "issue form" is the impact on performance.
Does this make the language more or less easy to implement efficiently. I'm
thinking about adding a "Performance Impact" to the cleanup form, since it
seems to be an undercurrent in a lot of the discussions.

What do you think?