Subject: generalized boolean From: Erik Naggum <clerik@naggum.no> Date: 1997/12/27 Newsgroups: comp.lang.lisp Message-ID: <3092246640739854@naggum.no> 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/