From: Marco Antoniotti
Subject: (defmethod oops ((x atom)) ...)
Date: 
Message-ID: <y6c1ypfpgqv.fsf@octagon.mrl.nyu.edu>
Ooops

I just wrote a beautiful piece of code that uses

	 (defmethod oops ((x atom)) ...)

Unfortunately, it does not work, since it seems that ATOM is not
required to be a BUILT-IN class (or similar).

Am I correct in my interpretation of the CLHS on this matter?

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.

From: Kent M Pitman
Subject: Re: (defmethod oops ((x atom)) ...)
Date: 
Message-ID: <sfwheyb1fjc.fsf@world.std.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> Ooops
> 
> I just wrote a beautiful piece of code that uses
> 
> 	 (defmethod oops ((x atom)) ...)
> 
> Unfortunately, it does not work, since it seems that ATOM is not
> required to be a BUILT-IN class (or similar).
> 
> Am I correct in my interpretation of the CLHS on this matter?

Yeah, you're correct.  I run into this on the implementation of
FIXNUM, too, since I sometimes want to dispatch on that and can't.
ATOM's a type, not a class.  Ditto FIXNUM.

The problem with ATOM, if I remember right, is that its meaning is
(NOT CONS).  It's the union type of all classes other than CONS.
In general, one can't dispatch on NOT of any class.  Making it a class
would mean it was [probably almost uselessly] in the CPL of all classes
except CONS.  I think it was the right decision to leave it out.  ATOM
is really an antequated notion that was made far less relevant when arrays
came along.  When CONS was the only "container class", zillions of years
ago, then atom was a non-container.  But now it's just kind of random...
From: Marco Antoniotti
Subject: Re: (defmethod oops ((x atom)) ...)
Date: 
Message-ID: <y6cd78yq3d3.fsf@octagon.mrl.nyu.edu>
Kent M Pitman <······@world.std.com> writes:

> Marco Antoniotti <·······@cs.nyu.edu> writes:
> 
> > Ooops
> > 
> > I just wrote a beautiful piece of code that uses
> > 
> > 	 (defmethod oops ((x atom)) ...)
> > 
> > Unfortunately, it does not work, since it seems that ATOM is not
> > required to be a BUILT-IN class (or similar).
> > 
> > Am I correct in my interpretation of the CLHS on this matter?
> 
> Yeah, you're correct.  I run into this on the implementation of
> FIXNUM, too, since I sometimes want to dispatch on that and can't.
> ATOM's a type, not a class.  Ditto FIXNUM.
> 
> The problem with ATOM, if I remember right, is that its meaning is
> (NOT CONS).  It's the union type of all classes other than CONS.
> In general, one can't dispatch on NOT of any class.  Making it a class
> would mean it was [probably almost uselessly] in the CPL of all classes
> except CONS.  I think it was the right decision to leave it out.  ATOM
> is really an antequated notion that was made far less relevant when arrays
> came along.  When CONS was the only "container class", zillions of years
> ago, then atom was a non-container.  But now it's just kind of random...

Yep.  I figured that out.

However I like to write things like

	(defmethod zut ((x t))
            (error "In package ZOT, ZUT undefined for ~S."
                   x))

and then dispatch on the actual implementation classes.  Basically I
want to control the "NO-APPLICABLE-METHOD" error.

It happens tha I was working on a

        (defmethod zut ((x list)) ...)

and writing

        (defmethod zut ((x atom)) ...)

would also catch the

        (defmethod zut ((x (eql nil))) ...)

and all the

        (defmethod zut ((x vector)) ...) ; etc etc

If you have a better suggestion about how to write this sort of code,
I will gladly adop it.

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.
From: Marco Antoniotti
Subject: Re: (defmethod oops ((x atom)) ...)
Date: 
Message-ID: <y6c7kz6q35g.fsf@octagon.mrl.nyu.edu>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> Kent M Pitman <······@world.std.com> writes:

	...	

> Yep.  I figured that out.
> 
> However I like to write things like
> 
> 	(defmethod zut ((x t))
>             (error "In package ZOT, ZUT undefined for ~S."
>                    x))
> 
> and then dispatch on the actual implementation classes.  Basically I
> want to control the "NO-APPLICABLE-METHOD" error.

Dah!  I just understand the depth of my ignorance.
NO-APPLICABLE-METHOD is a generic function and my very dear friend in
this case.

I see the light.  By defining methods on NO-APPLICABLE-METHOD I should
be able to "free" the

	(defmethod zut ((x t)) ...)

as the default handler.

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.