The problem with the name 'remove-if-not' is that it's both more fundamental and much more common in actual use than 'remove-if', yet its name is both longer to

The problem with the name 'remove-if-not' is that it's both more fundamental and much more common in actual use than 'remove-if', yet its name is both longer to type and conceptually more complex. Selecting a subcollection of elements that satisfy a predicate is a natural primitive. My favorite name for it is 'filter'; that's what I've called it in FSet [0]. I haven't defined 'filter-not'; usually the predicate is an explicit lambda expression, in which case adding the negation is straightforward, and even when a lambda is not needed, it's easy enough to write something like '(filter (complement #'integerp) ...)'. Anyway, even though I prefer 'filter', I could live with 'keep-if'. And by the argument I just gave, we wouldn't really need 'remove-if' anymore. The problem is 'delete-if'/'delete-if-not'; what do we do with them? I guess I would rename 'delete-if-not' to 'nkeep-if' (by analogy with 'nreverse' and 'nsubstitute') and discard 'delete-if'. [0] http://ergy.com/FSet.html http://ergy.com/FSet.html