The problem with the name &#x27;remove-if-not&#x27; is that it&#x27;s both more fundamental and much more common in actual use than &#x27;remove-if&#x27;, yet its name is both longer to type and conceptually more complex.<p>Selecting a subcollection of elements that satisfy a predicate is a natural primitive.  My favorite name for it is &#x27;filter&#x27;; that&#x27;s what I&#x27;ve called it in FSet [0].  I haven&#x27;t defined &#x27;filter-not&#x27;; 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&#x27;s easy enough to write something like &#x27;(filter (complement #&#x27;integerp) ...)&#x27;.<p>Anyway, even though I prefer &#x27;filter&#x27;, I could live with &#x27;keep-if&#x27;.  And by the argument I just gave, we wouldn&#x27;t really need &#x27;remove-if&#x27; anymore.  The problem is &#x27;delete-if&#x27;&#x2F;&#x27;delete-if-not&#x27;; what do we do with them?  I guess I would rename &#x27;delete-if-not&#x27; to &#x27;nkeep-if&#x27; (by analogy with &#x27;nreverse&#x27; and &#x27;nsubstitute&#x27;) and discard &#x27;delete-if&#x27;.<p>[0] <a href="http:&#x2F;&#x2F;ergy.com&#x2F;FSet.html" rel="nofollow">http:&#x2F;&#x2F;ergy.com&#x2F;FSet.html</a>