[pro] Style issue about predicates

[Ala'a Mohammad]

>......................., 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.