Are you sure that a special syntax would really help? Consider the following
(lambda (x)
(and (is-fruit-p x)
(or (grows-on-tree-p x)
(is-red-p x))))
and now the slightly more general
(lambda (x)
(and (is-fruit-p x)
(or (grows-on-tree-p x)
(eq (color x) 'red))))
or
(lambda (x)
(and (is-fruit-p x)
(or (grows-on-tree-p x)
(eq (color x) desired-color)))) ; desired-color captured lexical
Even if you build up a special syntax for predicates do you think the added language complexity is worth the rigidity you will get? For example are you going to define a predicate #'weights-exactly-five-ounces-p
? What about #'weights-up-to-and-including-six-and-half-ounces-p
?
If you start needing a parametric predicate and use lambda forms for that then using a combiner you're going to write more code than not using it because the (lambda (x) ...)
wrapper will be needed for each parametric term. More importantly that code will be also harder to read (in addition to having to learn a special new macro for predicate combination).
IMO it may make sense to write and/or combiners if you're passed in predicates and you need to pass predicates to someone else... but not for writing the code you used in the example; for that I'd write
(remove-if (lambda (x) (or (is-fruit-p x)
(is-red-p x)
(grows-on-trees-p x)))
list-of-objects)
Less to write, less to read, nothing extra to learn, trivial to parametrize.
Suppose for example that you want a list of fruits with the same color as the one you have (in mine
) and with same weight or possibly heavier...
(remove-if-not (lambda (x) (and (is-fruit-p x)
(eq (color x) (color mine))
(>= (weight x) (weight mine))))
objects)
(defun compliment (person &optional (stream t)) (format stream "Hello, ~a, you really look splendid today!" person))
– Demanding