Cleaning up predicate returns

[coffee@aerospace.aero.org]

> From: Masinter.pa@xerox.com
> Subject: Re: A simple question
> To: coffee@aerospace.aero.org

> If this were to be "cleaned up", in which way should it go?

> Should NOT, NULL, EQ and friends be required to return T or NIL always,
> rather than the less-specified "true" and NIL? Would this adversely
> affect performance? Are there any current implementations which don't
> return T or NIL for predicates?

I haven't put together a complete clean-up proposal yet, part of which
would certainly be discussion of implementation costs (regarding which
I have a bit of research to do!).

We have to be able to take the type of a NIL, and to recognize NIL as a
symbol, etc., so we can't realistically have (for example) ATOM return
its argument if true and NIL otherwise.

With CONSP, NUMBERP, STRINGP, INTEGERP, and all of the other predicates on
CLtL 74-76 except LISTP & COMMONP, however, there's no ambiguity in returning
the argument if true and NIL otherwise. I have grown accustomed to this
behavior in the ExperTelligence Lisps, and have to remind myself when writing
code that I'll need to port that this "filter" view of a predicate (as
opposed to the traditional "Boolean" view) is not portable at this time. We
have certainly grown used to the filter treatment of AND and OR, so I don't
think we're Boolean bigots here, and requiring this would not break code
unless it does things like testing for EQness to T instead of just using the
returned value as the Boolean.

The only argument I can see for _requiring_ return of strictly T or NIL, 
in these cases or in all of the currently indeterminate cases -- and
it may be a good argument at that -- is that it promotes portability by
preventing programmer reliance on a discretionary implementation that might,
for example, have LISTP return the object if it is a non-empty list and return
merely T for the empty list (nil otherwise). I don't favor this as standard
behavior, since LISTP could then return either a list or the T atom as
"true," meaning that code would need to check for each and be just
as ugly (or worse) than if return is limited (or assumed to be limited) to
T or NIL strictly.

I stress that this is a "wouldn't it be nice if," based on my own ideas of
what makes good-looking code, _not_ yet researched to the point that I call
it a "proposal." The extent to which I get flamed will probably determine
whether it dies immediately :-).  I've run it past one other Lisper here
and been "Boolean bashed": he thought this style much less readable.
Of course, no one would _have_ to use the value as anything but a Boolean.

Regards, Pc^2