[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MEMBER, etc.



It seems that people are starting to discuss the question
of whether they, and the users of their Lisp systems,
will benefit from renaming MEMBER to MEMBERP in Common Lisp.

This subject is relevant to the question of whether to rename
it, but is not the same subject.  If anyone finds that his users
would benefit from the renaming, that is an additional reason
to make the renaming.  But the fact that some Lisp system,
such as NIL, has changed MEMBER, or is willing to change MEMBER,
only means the absense of a reason to rename the function in
Common Lisp.  It is not any sort of reason NOT to rename it.

If the renaming were done, presumably GSB would not want to
change the definition of MEMBER a second time.  That is fine.
Common Lisp would no longer define MEMBER and there would be
no reason he had to change it.  Nobody would have to change it.
NIL users would not be inconvenienced.

There are only two reasons I can see which could be used
to argue against the change:
1) the name MEMBER is a nicer name than MEMBERP (if it is one)
2) some people have written portable code that uses MEMBER.

It seems clear that the amount of such portable code is small
at this date compared to the amount of Lisp machine code.
1) is a matter of opinion and one could see it either way.

The functions that are the problem are MEMBER, ASSOC, RASSOC,
DELETE etc. and REMOVE etc.  This is what I suggest to do about
them:

MEMBER -> MEMBERP
ASSOC, RASSOC:
 Delete them.  It is easy to use FIND for this purpose,
 as described in the documentation of FIND.
 This can be seen as making the design cleaner.
REMOVE:
 Rename to FILTER, and change the sense of the test.
 That is, change :TEST to :TEST-NOT and vice versa;
 an element is kept if it passes the test.
DELETE
 Rename to NFILTER and change the sense of the test.

SUBSET is a possible alternative to FILTER.
Or perhaps REMOVE -> FIlTER-MATCH,
REMOVE-IF-NOT -> FILTER, REMOVE-IF -> FILTER-NOT.