Subject: Re: Looking for a LISP function or macro ...
From: Erik Naggum <>
Date: 1998/09/19
Newsgroups: comp.lang.lisp
Message-ID: <>

* Kent M Pitman <>
| So would I if not for the fact that these functions (or even their
| negations) aren't used much, and are totally easy to write yourself
| if missing. 

  "it's easy to write it yourself" is the Scheme argument.  for a single
  function, it's hard to refute, except for "why _should_ programmers
  everywhere need to do it for themselves?".  multiplied by thousands of
  functions, it doesn't really work that well, anymore.  moreover, I have
  yet to see an implementation that does away with the closure consing and
  function call overhead of COMPLEMENT in _all_ cases, which I doubt is
  even possible, so to write these functions _well_ would require writing
  the internals yourself, or you penalize people for their needs.  that's
  not what I associate with Common Lisp.

  a quick scan of my last project's source (120K, kept small through very
  hard work), shows that I found these -IF-NOT functions useful:

      DELETE-IF-NOT	of UPPER-CASE-P, to retain initials
      POSITION-IF-NOT	of WHITESPACE-CHAR-P  (for a non-consing TRIM)
      MEMBER-IF-NOT	of EMPTY, a test for a blank line, etc
		    and of NULL, to remove initial NILs in a list

  in all of these cases, I would either cons up a closure with COMPLEMENT,
  write a new function with the reversed sense without closure consing or
  extra function call overhead, or _hope_ there's a compiler macro that
  reverts to internal -IF-NOT functions.  what, precisely, is gained by
  removing these functions?  I'd say "purity of design", and that would
  have been valid if such was an expressed goal of the language, and it
  didn't have serious costs associated with it.
| It's clear the :TEST-NOT arguments are a semantic problem that has to be
| removed.

  as I have already stated, but once again for the record: :TEST-NOT should
  go, and this I have thought for years.  removing :TEST-NOT would not be
  done out of "purity of design" concerns, but out of concern for the fuzzy
  semantics of specifying both :TEST and :TEST-NOT, which might easily
  happen when writing the kind of functions that are suggested replacements
  for REMOVE-IF-NOT.  since that is possible, we have a real conflict that
  cries out for a solution.  I don't _like_ the name "complement" at all,
  but if I can bury it sufficiently, I hope I won't notice it sticking out.

| And users aren't exactly screwed if they do go away some year.  I
| didn't test the following, but imagine it or something like it would
| work, both today and years from now when remove-if-not goes away.
| (eval-when (:execute :compile-toplevel :load-toplevel)
|   (when (fboundp 'remove-if-not)
|     (pushnew :remove-if-not *features*)))
| #-remove-if-not
| (proclaim '(inline remove-if-not)) ;avoid overhead of extra function call
| #-remove-if-not
| (defun remove-if-not (predicate sequence &rest keys &key &allow-other-keys)
|   (apply #'remove-if (complement predicate) sequence keys))

  once upon a time, you said something to the effect that Common Lisp saved
  you heaps of code that you previously had had to add to every project.
  we're moving backwards, now, where people have to add such code.  users
  _are_ screwed in many ways by this COMPLEMENT business.  debuggability
  goes down, performance is hit, etc, etc.  to re-supply REMOVE-IF-NOT
  after X3J13 takes it away needs reimplementing the function, not just
  slapping a couple wrappers around existing functions and hope nobody will
  notice that they can no longer fix bugs in the predicate function and
  continue, or that APPLY crops up much more often than it should during
  profiling.  an implementation that sports compiler macros that attempt to
  make REMOVE-IF fast by pre-determining keyword arguments would not be
  able to optimize the call unless COMPLEMENT itself were to be used in the
  _actual_ form.  thus, you make code much less readable in order to save
  on a "bloat" factor that is about two order of magnitude smaller than
  that of C++ or Java.

| Anyway, my point is that the few users who even use these functions can
| EASILY compensate for their absence.

  I take it that no study of the effects of the introduction of COMPLEMENT
  has been made.  COMPLEMENT has _very_ high costs.  they have _not_ been
  defended, nor have they been compared to the gains from removing -IF-NOT,
  if any.  as I see it, COMPLEMENT is a wanton waste of resources.  I have
  no qualms about spending lots of resources for a good reason; it's only
  the _wanton_ part I object to.

| And probably, if/when we do remove them, we'll somewhere publish the
| workaround code so users don't even have to do that much work.

  well, _I'm_ certain that vendors will protect user investments even if
  the committee abandons that goal.

  take :TEST-NOT and be satisfied, is my suggestion.  don't touch -IF-NOT.

  ATTENTION, all abducting aliens!  you DON'T need to RETURN them!