MEMBER, etc.

[Scott E. Fahlman <Fahlman@CMU-CS-C>]

I agree with Stallman that at this point we should not be discussing the
merits and aesthetics of MEMBER vs. MEMBERP.  We did that once, and made
a decision.  The time for aesthetic improvements to the language (first
edition) is over.  For that reason, I find his poll of MIT users on
whether they want good old-fashioned MEMBER to stay the way it is to be
totally irrelevant to this discussion; last August, that might have been
valuable input, but not now.

I disagree strongly with Stallman's view that we have some obligation to
make his proposed changes unless someone comes up with a compelling
reason not to.  Whether RMS heard about it or not, the manual is frozen
and the presumption must be strongly in favor of not making any changes
to it.  It now requires a truly compelling reason to make any change.

We are considering the MEMBER => MEMBERP change, if at all, because it
is a sort of emergency request.  Stallman's claim is that (1) changing
to MEMBERP is so trivial a change that we should consider it even at
this late date, (2) it costs existing implementations nothing to make
the change, and (3) it causes the MIT/LMI/Stallman implementation
terrible problems to leave MEMBER the way it currently is, with EQL as
the default.  In other words, according to RMS, the cost to him of not
making the change is very much greater than cost to the rest of us of
making the change.  That is the ONLY reason that I can see why a change
of this sort would be considered now.

After thinking about this issue, I now believe that all three of the
above-mentioned points are greatly exaggerated.

(1) As we see from RMS's note, the proposal now is to alter MEMBER,
ASSOC, RASSOC, DELETE, DELETE-IF, DELTE-IF-NOT, REMOVE, REMOVE-IF, and
REMOVE-IF-NOT.  In several cases, the proposal involves changing the
sense of a test.  The ASSOC and RASSOC functions are to be replaced with
uses of FIND.  This is not such a trivial change any more.

(2) The claim is that since Common Lisp would no longer define MEMBER,
ASSOC, RASSOC, DELETE, DELETE-IF, DELETE-IF-NOT, REMOVE, REMOVE-IF, and
REMOVE-IF-NOT, those of us who have made the transition already (and our
users) could just leave these functions as they are and add the new
forms beside them.  Thus, RMS claims, the cost of this conversion is zero
for us.  I can't speak for the other implementations, but we at CMU are
quite strongly committed to working within the bounds of portable Common
Lisp wherever possible.  This means that if MEMBER is not a part of
Common Lisp and MEMBERP is, we have to change our code to use MEMBERP.
RMS is technically correct -- if we didn't do this, our code would still
run -- but we are quite unwilling to have fossilized relics of earlier
editions of Common Lisp sprinkled through our system.  So, in realistic
terms, the cost to us of making all of RMS's changes is far from zero.
I'm not saying that it is a terrible cost, but it is significant.  A far
greater cost, in my opinion, would be the confusion in the minds of
those users who have already made the transition to the new Common Lisp
-- one of the most confusing things you can do is to make a decision on
something like this, sell people on it, and then reverse it six months
later.

(3) After giving the matter some thought, I no longer believe that a
one-time change-over to use the EQL versions of MEMBER and friends would
be such a big deal for RMS and his users.  In the time he has spent
arguing about this, he could easily have implemented an Emacs or Zwei
command to turn all occurrences of (MEMBER x y) in a file into (MEMBER x
y :TEST #'EQUAL), and likewise for the other forms he's worried about.
He might not WANT to make the changeover, but it would not be the
terrible ordeal that he suggests.  In fact, I believe that it would be
no more work for him to make that change than for us to make the changes
he proposes.  A lot of people with a lot of working code have already
made that change, and have lived to tell about it.

So, while I thought it appropriate to bring Stallman's urgent request to
the attention of this list, my own opinion is that the case is not
strong enough to warrant making these changes to the language definition
at the last minute.

-- Scott