generalized boolean
Erik Naggum
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".
#\Erik
--
The year "98" was new 1900 years ago. | Help fight MULE in GNU Emacs 20!
Be year 2000 compliant, write "1998"! | http://sourcery.naggum.no/emacs/
Kent M Pitman
Erik Naggum <cle...@naggum.no> writes:
> 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".
Well, designators are largely used as inputs to functions and you're
just observing the well-known symmetry between input and output. I
think the term "generalized boolean" existed in spoken language which
is why I decided to go with that.
But I agree with your claim that a resolver is a good idea. Actually,
a theory of designator specs and the ability to add methods to a
resolver for the atomics might be good. The main problem is that, unlike
some other big things we might add that we know are "in there anyway",
I bet no implementation goes through a general interface. Still, I suppose
they could be.
In the T dialect of Scheme, we had a TRUE? predicate which would return
T or NIL. Then we had various pre-defined contractions like
(member? x y) == (true? (member x y))
I think a TRUEP operator wouldn't hurt CL (and I often define one
myself). If defined by the standard, it could be interestingly
optimized in certain implementations at certain optimization levels
when enclosing a form that at that setting might or might not return a
real boolean.
(Anyway, don't blame this problem on "generalized booleans". They've
existed since 1984 CLTL. The only thing I did was change the name to
make what was already true "apparent"; the occasional ability of
people like you to articulate a previously-vague pain so clearly is a
mark of the success of the renaming. :-)
--Kent (on vacation, but also sick with a cold,
so reading newsgroups for amusement)