......................., do you think it's better to code it so that it always returns "t" for the true case?
my current practice is to use other-than-nil as truth value in predicates. Even if current application needs t or nil only. this will help avoid breaking older code (which did not assume 't' is the only truth) in case I find a way for returning a useful other-than-nil value in future. OTOH, I think this (using a generalized-boolean rather than boolean) will mesh well with CL style (most of it).
In case of 'nil' as a useful value, I'll return multiple values similar to gethash.
also I try (most of the time if possible) to adhere to the definitions in the glossary of CLHS. in this case it defines a predicate as a function returning generalized-boolean as its first value. (I do this in part so that CLHS wil act as a part in documenting the terms used in my own documentation like doc strings and others, in other words having a common glossary to use)
Furthermore, the contract of the function should make it clear that the returned value is an a true/false context.
I'll use the followings (from CLHS glossary) in documenting the return value(s) Boolean for t and nil symbols Generalized Boolean for nil and others-are-true
(defun ... ... (when (fn1 arg2 arg2) t))
or use
(defun truep (object) (not (not object)) ;; 'not' is specified to return either nil or t only
(defun ... .... .... (truep (predic1 arg1 arg2))
;; both name and implementation on comp.lang.lisp from Kent (~ around 13 years ago)
Regards,
Ala'a Mohammad.