MEMBER

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

Recently RMS polled asked the opinion of people on this list about the
plan to change the definition of MEMBER in Common Lisp.  Some of the
responses indicated some confusion as to what we (the people who have
been working for the last two years to hammer out a Common Lisp
definition) are actually proposing.  I would like to clarify this before
too many people get too upset.

For a long time, Lisp has had EQUAL and EQ versions of some of the
important operators: MEMBER/MEMQ, DELETE/DELQ, etc.  Modern lisps have a
lot more data types and a lot more specialized equality predicates: EQL,
=, STRING=, etc.  Things began to multiply.  At one point, we had some
600 of these sequence functions, including such gems as RASS-EQL and
DEL-FROM-END-IF-NOT.  The decision was made to to cut this number down
by providing a small number of powerful generic functions that could be
further specialized by the use of keywords.  These generic functions
were uniformly given the "good" names.  Thus we have operators like
REPLACE, REMOVE, POSITION, and MEMBER, each of which takes a :TEST
keyword telling what sort of equality test to use.  In all cases, the
default test is EQL, by far the most useful.  (Though they are
redundant, we kept around MEMQ, DELQ, and ASSQ as historical monuments.)

So, if you want something that does what (MEMBER x y) does in Maclisp,
you have to say (MEMBER x y :TEST #'EQUAL) in Common Lisp.  We
considered many alternatives to this scheme: making EQUAL the universal
default, having MEMBER default to EQUAL while the other functions
default to EQL, or thinking up a new name for the function that does
what MEMBER does.  In the end, we decided to do what I described above.
It seemed clear to us that this would be best in the long run, after
everyone has forgotten the details of earlier Lisps, and it seemed like
an easy (mechanizable) conversion to put the :TEST 'EQUAL into every
MEMBER call in a file.

I'm sure that many people will disagree with this choice, but it was not
a frivolous or hasty decision; a lot of experienced Lisp implementors
agonized for a long time over this one, and finally reached an agreement
acceptable to all those participating in the Common Lisp design at that
time.  That is why we are reluctant to re-open the debate nine-months
later, only days before the Common Lisp manual goes to press.

-- Scott Fahlman