How can I specialize a method parameter to a boolean ?
CL-USER 7 > (defmethod f ((a number)))
#<STANDARD-METHOD F NIL (NUMBER) 203C35E4>
CL-USER 8 > (defmethod f ((a boolean)))
Error: BOOLEAN is not the name of a class
1 (continue) Try finding the class BOOLEAN again
2 (abort) Return to level 0.
3 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other
options
Ok, boolean is a type, not a class.
So how can I specialize a method parameter to a boolean except with eql
specializers
Thanks,
Marc Battyani
In article <···············@upnetnews02.moswest.msn.net>,
Marc Battyani <·············@email.msn.com> wrote:
>Ok, boolean is a type, not a class.
>So how can I specialize a method parameter to a boolean except with eql
>specializers
You can't. BOOLEAN is basically just an abbreviation for (MEMBER T NIL) or
(OR (EQL T) (EQL NIL)). Neither of these is the kind of type that has a
corresponding class.
In general, classes correspond to representational types, not to more
abstract types like booleans.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Barry Margolin <······@bbnplanet.com> wrote:
>
> BOOLEAN is basically just an abbreviation for (MEMBER T NIL) or
> (OR (EQL T) (EQL NIL)). Neither of these is the kind of type that has a
> corresponding class.
>
> In general, classes correspond to representational types, not to more
> abstract types like booleans.
Well, we do have a class NULL, which is just an abbreviation for
(MEMBER NIL). It would not disturb the class system to add a class
BOOLEAN between NULL and SYMBOL:
SYMBOL
|
BOOLEAN
|
NULL
Bruno
In article <··········@news.u-bordeaux.fr>,
Bruno Haible <······@clisp.cons.org> wrote:
>Barry Margolin <······@bbnplanet.com> wrote:
>>
>> BOOLEAN is basically just an abbreviation for (MEMBER T NIL) or
>> (OR (EQL T) (EQL NIL)). Neither of these is the kind of type that has a
>> corresponding class.
>>
>> In general, classes correspond to representational types, not to more
>> abstract types like booleans.
>
>Well, we do have a class NULL, which is just an abbreviation for
>(MEMBER NIL). It would not disturb the class system to add a class
>BOOLEAN between NULL and SYMBOL:
>
> SYMBOL
> |
> BOOLEAN
> |
> NULL
NIL is a very special object, of its own, unique data type. The NULL class
refers to that type, it's not just an abbreviation for (MEMBER NIL). If
you want to think of it as an abbreviation, it would be for (EQL NIL),
which *is* something you can use as a method specializer.
The suggested hierarchy would not disturb the class system, but it would be
a bitch to implement efficiently. CLOS method dispatch requires that the
system be able to go from an object to its class quickly. This generally
means dispatching on the internal, representational data type. The symbol
T has the same representational type as all other symbols, so the BOOLEAN
class would have to be handled specially.
If you need to do this frequently, it shouldn't be too hard to define a
macro to do it. It would expand into a pair of DEFMETHODs, one specialized
on the class NULL, the other specialized on (EQL T), with the same body.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
······@clisp.cons.org (Bruno Haible) writes:
> Well, we do have a class NULL, which is just an abbreviation for
> (MEMBER NIL). It would not disturb the class system to add a class
> BOOLEAN between NULL and SYMBOL:
>
> SYMBOL
> |
> BOOLEAN
> |
> NULL
It would not disturb the class system, but it would disturb my
stomach.
NIL has three interesting qualities:
N1. It is the (only) false value of booleans.
N2. It is the ultimate tail of a proper list, ().
N3. It is a constant variable whose value is boolean false (i.e., itself).
BOOLEAN has two elements:
- The symbol T, the canonical truth value of booleans.
- The symbol NIL, the (only) false value of booleans.
The class NULL is a subclass of symbol only because of N2.
The symbol NIL is a member of BOOLEAN only because of N1.
The concept of NULL is therefore only a subclass of BOOLEAN for incidental reasons.
Abstractly, it's an inconvenience that the class BOOLEAN selects class NULL.
I wouldn't argue for removing the NIL/() overlap, as Scheme has done, but
I don't think there's any reason to make things gratuitously messy by making
people confuse NULL (a list classs) with BOOLEAN (a true/false class).
People already routinely confuse NIL with () by using NULL where they want NOT,
or vice versa. e.g., (NOT (NULL (MEMBER ...)))
MEMBER doesn't return () when it fails, it returns NIL.
These are of course representationally the same, but not intentionally the same.
MEMBER isn't returning an empty tail; it returns either a tail if it succeeds
or false if there is no appropriate tail.