Subject: generalized boolean
From: Erik Naggum <>
Date: 1997/12/27
Newsgroups: comp.lang.lisp
Message-ID: <>

every now and then, I actually need a specific boolean (i.e., `t' or `nil')
where a function is specified to return a generalized boolean, such as
when I'm storing it somewhere semi-permanent.  some functions return as a
generalized boolean a large object that "hangs around" much too long if it
is stored away.  it's kind of ugly to fake this with (and <form> t), but
it's also hard to figure out when to avoid it.

I envision a (standard) function `boolean' that returns `t' or `nil'
according as its generalized boolean argument is true or false, but which
wouldn't actually get called in compiled code.  this can be faked with
compiler macros, but to avoid the redundant test, one needs to know which
functions return `t' or `nil' at which optimization settings.  this would
require compiler and vendor support to be correct, and thus would seem like
a good candidate for standardization.

e.g., it seems that Allegro CL 4.3.1 already "knows" that some functions
return `t' or `nil' at some optimization settings, and thus (and <form> t)
does not produce extraneous code.  however, some older (1992) code I have
worked with lately that needed a specific boolean would do

    #+excl (and <form> t) #-excl <form>

and this led me to believe that somebody somewhere had been bitten by this
"generalized boolean" stuff and had just smacked together a local (wrong)
solution to a more general problem.

sometimes, I think the "generalized boolean" is just another phrase for
"boolean designator", which would have been more appropriate in some cases.
since I also tend to think that all designators should have "resolvers" in
the standard, `boolean' fits right in with my "designator frustration".

The year "98" was new 1900 years ago.  |  Help fight MULE in GNU Emacs 20!
Be year 2000 compliant, write "1998"!  |