Subject: Re: Looking for a LISP function or macro ...
From: Erik Naggum <erik@naggum.no>
Date: 1998/09/18
Newsgroups: comp.lang.lisp
Message-ID: <3115133657941919@naggum.no>

* Barry Margolin <barmar@bbnplanet.com>
| Use REMOVE-IF and invert the sense of the test (using the COMPLEMENT
| function, if necessary).  This supercedes the deprecated REMOVE-IF-NOT
| function.

  I find this a conceptually horrible suggestion.  REMOVE-IF-NOT is at
  least possible to deal with as an idiom.  REMOVE-IF of the COMPLEMENT of
  the function I really want in order to _keep_ certain elements is exactly
  how I would have force people to do things if I were into purity for its
  own sake and thought utility and pragmatics were stupid concerns.

  not wanting to deal with the very annoying COMPLEMENT function, I have
  defined functions COLLECT and RETAIN as the semantic complements of
  REMOVE and DELETE, with -IF _and_ -IF-NOT variants.  (COLLECT is a whole
  lot different from REMOVE with some keyword arguments, by the way.)

(defun collect-if (predicate list &rest keys)
  "Return a list of each element from LIST that satisfies PREDICATE.
Accepts the same keyword arguments as REMOVE-IF."
  (apply #'remove-if-not predicate list keys))

  I see no reason at all to deprecate -IF-NOT.  the reason for deprecating
  :TEST-NOT is in a whole different category, since it is unspecified what
  :TEST FOO :TEST-NOT BAR should mean, i.e., when specified at the same
  time, and this problem _does_ come up when applying a function an unknown
  list of keyword-value pairs.  no such thing could ever happen to -IF-NOT
  functions, yet it is apparent from the write-ups that -IF-NOT only got
  deprecated out of some misguided sense of symmetry with :TEST-NOT.

  incidentally, the above function can be written with REMOVE-IF and the
  annoying COMPLEMENT function if one is so inclined.  in any case, I think
  that if you think you need COMPLEMENT, you should define a new function
  that conveys the new purpose, and use that instead.  it may well use
  COMPLEMENT internally.  whether the new function is the test function or
  the caller of the test function depends on the purpose.  the same goes
  for the all the other function-building functions that Dylan has and
  which it's sort of fun to play with, but which I think should not be used
  as open-coded idioms -- better to use them in implementations of
  something that reflects how you think.
  
#:Erik
-- 
  ATTENTION, all abducting aliens!  you DON'T need to RETURN them!