another frustrating learner question, CLOS

Learning Lisp is like pulling teeth, except more painful!

Here is a code snippet copied directly from Figure 11.2, page 178, of
Graham's 'ANSI Common Lisp':

(defclass rec ()
(height width))
(defclass cir ()
(radius))
(defmethod area ((x rec))
(* (slot-value x 'height) (slot-value x 'width )))
(defmethod area ((x cir))
(* pi (expt (slot-value x 'radius) 2)))

Here is the error message gives when I try to compile this:

NO-APPLICABLE-METHOD: When calling #<GENERIC-FUNCTION FIND-METHOD>
with arguments (#<COMPILED-CLOSURE
AREA>
NIL (REC) NIL), no method is applicable.
[Condition of type METHOD-CALL-TYPE-ERROR]

I've tried the usual sources of help, including Keene, Lamkins, and
Seibel, and the HyperSpec, but I still can't figure out why this won't
compile.

Like I said, more painful than pulling teeth ... unless somebody notes
that I made a stupid typo that I have overlooked.

CC.

> Here is a code snippet copied directly from Figure 11.2, page 178, of
> Graham's 'ANSI Common Lisp':
>
> (defclass rec ()
> (height width))
> (defclass cir ()
> (radius))
> (defmethod area ((x rec))
> (* (slot-value x 'height) (slot-value x 'width )))
> (defmethod area ((x cir))
> (* pi (expt (slot-value x 'radius) 2)))
>
> Here is the error message gives when I try to compile this:

I copied your snippet into a file called "scratch.lisp" and did
(compile-file "scratch.lisp") and didn't get any errors. What kind of
compiling did you do that triggered an error?

Zach

In article <5bf2d29e-ea74-4c9c-a67d-e10c46b8e14f@d27g2000yqf.googlegroups.com>,
cartercc@gmail.com says...
>
> Learning Lisp is like pulling teeth, except more painful!
>
> Here is a code snippet copied directly from Figure 11.2, page 178, of
> Graham's 'ANSI Common Lisp':
>
> (defclass rec ()
> (height width))
> (defclass cir ()
> (radius))
> (defmethod area ((x rec))
> (* (slot-value x 'height) (slot-value x 'width )))
> (defmethod area ((x cir))
> (* pi (expt (slot-value x 'radius) 2)))
>
> Here is the error message gives when I try to compile this:
>
> NO-APPLICABLE-METHOD: When calling #<GENERIC-FUNCTION FIND-METHOD>
> with arguments (#<COMPILED-CLOSURE
> AREA>
> NIL (REC) NIL), no method is applicable.
> [Condition of type METHOD-CALL-TYPE-ERROR]
>
> I've tried the usual sources of help, including Keene, Lamkins, and
> Seibel, and the HyperSpec, but I still can't figure out why this won't
> compile.
>
> Like I said, more painful than pulling teeth ... unless somebody notes
> that I made a stupid typo that I have overlooked.
>
> CC.


Your code works fine here (on SBCL). I don't see anything weird with it, except
that you didn't define any accessors or initargs.
Here's some test code:
(let ((rec (make-instance 'rec))
(cir (make-instance 'cir)))
(with-slots (height width) rec
(setf height 10 width 20)
(setf (slot-value cir 'radius) 30)
(values
(area rec)
(area cir)))) ;=>200, 2827.4333882308138d0

Or rewritten with initargs/accessors.

(defclass rectangle ()
((height :initarg :height :accessor height)
(width :initarg :width :accessor width)))

(defclass circle ()
((radius :initarg :radius :accessor radius)))

(defmethod area ((x rectangle))
(* (height x) (width x)))

(defmethod area ((x circle))
(* pi (expt (radius x) 2)))

(let ((rec (make-instance 'rectangle :height 10 :width 20))
(cir (make-instance 'circle :radius 30)))
(values (area rec) (area cir))) ;=>200, 2827.4333882308138d0

On 2010-02-24 23:08:02 +0000, ccc31807 said:

> (defclass rec ()
> (height width))
> (defclass cir ()
> (radius))
> (defmethod area ((x rec))
> (* (slot-value x 'height) (slot-value x 'width )))
> (defmethod area ((x cir))
> (* pi (expt (slot-value x 'radius) 2)))
>
> Here is the error message gives when I try to compile this:

What do you mean by "when I try to compile this"? If you put the above
in a file and compile it with COMPILE-FILE I think this should
definitely be fine.

ccc31807 <cartercc@gmail.com> writes:
> (defclass rec ()
> (height width))
> (defclass cir ()
> (radius))
> (defmethod area ((x rec))
> (* (slot-value x 'height) (slot-value x 'width )))
> (defmethod area ((x cir))
> (* pi (expt (slot-value x 'radius) 2)))
>
> Here is the error message gives when I try to compile this:
>
> NO-APPLICABLE-METHOD: When calling #<GENERIC-FUNCTION FIND-METHOD>
> with arguments (#<COMPILED-CLOSURE
> AREA>
> NIL (REC) NIL), no method is applicable.
> [Condition of type METHOD-CALL-TYPE-ERROR]

I cut and pasted that into SBCL on OSX and it was fine. What Lisp
are you using?

Regards,

Patrick

------------------------------------------------------------------------
http://www.softwarematters.org
Large scale, mission-critical, distributed OO systems design and
implementation. (C++, Java, Common Lisp, Jini, middleware, SOA)

On Feb 24, 3:08*pm, ccc31807 <carte...@gmail.com> wrote:
> Learning Lisp is like pulling teeth, except more painful!
>
Learning something new should be fun. I at least enjoyed it very so
far, but then, I enjoyed also learning Forth, C and Pascal back when.
Even C++ and Java for a while. Oh, and in Lisp, I stayed so far away
from OOP - I just didn't have a need for it.

If it's painful, chances are you're doing it wrong. Keep in mind that
for virtually all problems there are multiple solutions. Pick an easy
one, go with the flow.

On Wed, 24 Feb 2010 15:08:02 -0800, ccc31807 wrote:

> Learning Lisp is like pulling teeth, except more painful!

Either Lisp is not a good match for you, or you are not ready for it
yet. In either case, you are not likely to benefit from learning Lisp
for now.

Regarding your code: as others have said, it should work fine. You
must be making some mistake when you are running/compiling your
program.

Tamas

On 2010-02-24, ccc31807 <cartercc@gmail.com> wrote:
> Learning Lisp is like pulling teeth, except more painful!
>
> Here is a code snippet copied directly from Figure 11.2, page 178, of
> Graham's 'ANSI Common Lisp':
>
> (defclass rec ()
> (height width))
> (defclass cir ()
> (radius))
> (defmethod area ((x rec))
> (* (slot-value x 'height) (slot-value x 'width )))
> (defmethod area ((x cir))
> (* pi (expt (slot-value x 'radius) 2)))
>
> Here is the error message gives when I try to compile this:

> NO-APPLICABLE-METHOD: When calling #<GENERIC-FUNCTION FIND-METHOD>
> with arguments (#<COMPILED-CLOSURE
> AREA>
> NIL (REC) NIL), no method is applicable.
> [Condition of type METHOD-CALL-TYPE-ERROR]

The error message is impossible from compiling /just/ the above, and nothing
more. It's a message about an erroneous call of the AREA generic function;
but your example has no call at all, only method specializations
defining two flavors of AREA.

It's puzzling because it seems to be complaining that there is no AREA
specialization which takes a REC, which you have in fact defined.

Why don't you post minimal program (all in one file, if possible)
which reproduces the error message, along with steps to reproduce.
Which Lisp implementation are you invoking, in what manner, etc.

On Feb 25, 2:45*am, Kaz Kylheku <kkylh...@gmail.com> wrote:
> The error message is impossible from compiling /just/ the above, and nothing
> more. *It's a message about an erroneous call of the AREA generic function;
> but your example has no call at all, only method specializations
> defining two flavors of AREA.

I sometimes think that the programming gods get together at night for
code reviews, and sometimes where there has been a shedding of blood
in an amount sufficient to atone for programming sins, graciously
extend mercy and forgiveness, even though it's neither earned nor
merited by the programmer.

Yesterday, I had emacs and slime open all day hacking with Lisp during
free moments, and at the end of the day was reviewing Ch 11 of 'ANSI
Common Lisp' when I had the problem. I don't (usually) post to a news
group about an error unless I am at my wit's end, which I was
yesterday evening.

This morning, with a fresh slate, I opened the file, compiled it, and
it ran perfectly. I don't know what I was doing wrong, and certainly
didn't do anything to fix it, so the only explanation I can give is
the remission of programming sins by the programming gods.

CC.

On Feb 25, 1:23*am, Tamas K Papp <tkp...@gmail.com> wrote:
> On Wed, 24 Feb 2010 15:08:02 -0800, ccc31807 wrote:
> > Learning Lisp is like pulling teeth, except more painful!
>
> Either Lisp is not a good match for you, or you are not ready for it
> yet. *In either case, you are not likely to benefit from learning Lisp
> for now.

I strongly disagree. I don't believe that people are 'matched' to
programming languages any more than they are 'matched' to human
languages. A good programmer can program in any language whether he
knows it or not, and a poor programmer can't program in any language
whether he know it or not.

As to 'being ready' this is like lifting weights. The only way you can
be ready to lift heavy weights is to start by lifting light weights
and build yourself up. How could anyone 'be ready' to learn any
language if he never exercised himself by attempting to learn the
language?

> Regarding your code: as others have said, it should work fine. *You
> must be making some mistake when you are running/compiling your
> program.

See my other post this morning. Obviously, I made some mistake, which
was probably related to fooling around all day and corrupting the
environment in some kind of way. I had probably defined a version of
the 'area' function earlier in the day which the environment still
'remembered' and gave the error message. In a perfect world, the error
message would have been something like this: "Hey, you dummy, you
already defined an area function, so you need to give this one a
different name."

Thanks, CC.

ccc31807 <cartercc@gmail.com> writes:

> This morning, with a fresh slate, I opened the file, compiled it, and
> it ran perfectly. I don't know what I was doing wrong, and certainly
> didn't do anything to fix it, so the only explanation I can give is
> the remission of programming sins by the programming gods.

Blaming gods is a great way to absolve yourself of responsibility and
avoid learning from your actions.

You accumulated state in your system that interfered with its normal
operation, and you fixed it by restarting from a clean state. This is a
drastic but sometimes effective problem-solving technique, and can be
the easiest thing to do when you don't yet know how to inspect and
manipulate the system's accumulated state to get it back in order.

No gods were involved in the making or solving of this problem.

When I first started using Linux, I accidentally unpacked a nethack
tarball in /dev. As I saw the file list flying by as they were deposited
all over that directory, I knew I could never find them all and clean up
the mess. So I erased my system and reinstalled it from
floppies. Problem solved; I didn't have any especially valuable state
worth preserving, anyway. Now that I know better, I feel fine about
building up important state on my Linux systems and have confidence in
my ability to recover from accidents without starting completely from
scratch.

Zach

On Feb 25, 9:31*am, Zach Beane <x...@xach.com> wrote:
> Blaming gods is a great way to absolve yourself of responsibility and
> avoid learning from your actions.

Are you serious? Or are you saying this with tongue firmly planted in
cheek? (I was attempting levity, which probably wasn't evident.)

> You accumulated state in your system that interfered with its normal
> operation, and you fixed it by restarting from a clean state. This is a
> drastic but sometimes effective problem-solving technique, and can be
> the easiest thing to do when you don't yet know how to inspect and
> manipulate the system's accumulated state to get it back in order.

Yeah, it took me about three microseconds to figure this out. That's
not the answer, and it's certainly not the question, but at least I
learned that this is a problem you can have, which isn't a problem in
my normal working environments.

> No gods were involved in the making or solving of this problem.

They were either the programming gods, or the programming fairies, or
the programming elves. There is simply no explanation other than
supernatural beings who interact with humans in an arbitrary and
capricious manner, making logic, reason, and science totally
illogical, unreasonable, and unscientific. ;-)

> worth preserving, anyway. Now that I know better, I feel fine about
> building up important state on my Linux systems and have confidence in
> my ability to recover from accidents without starting completely from
> scratch.

In my experience, a lesson really isn't driven home (as opposed to
just learning it) until it has been validated in the school of
practical experience. This has happened to me in the past, it will
happen in the future, and now I can began to explain it and develop
strategies to deal with it. It's all part of learning to use a new
language.

CC

On 2010-02-25 14:31:18 +0000, Zach Beane said:

> No gods were involved in the making or solving of this problem.

True, most of the Lisp gods are now dead or withdrawn

ccc31807 <cartercc@gmail.com> writes:

> On Feb 25, 9:31Â*am, Zach Beane <x...@xach.com> wrote:
>> Blaming gods is a great way to absolve yourself of responsibility and
>> avoid learning from your actions.
>
> Are you serious? Or are you saying this with tongue firmly planted in
> cheek? (I was attempting levity, which probably wasn't evident.)

I meant what I wrote.

>> You accumulated state in your system that interfered with its normal
>> operation, and you fixed it by restarting from a clean state. This is a
>> drastic but sometimes effective problem-solving technique, and can be
>> the easiest thing to do when you don't yet know how to inspect and
>> manipulate the system's accumulated state to get it back in order.
>
> Yeah, it took me about three microseconds to figure this out. That's
> not the answer...
[snip]

It is exactly the answer.

> I learned that this is a problem you can have, which isn't a problem
> in my normal working environments.

Problematic state can happen in many systems. Resetting a system is a
usually not necessary if you have the tools and skills needed to inspect
and manage the system's state. You have the tools but not the skills
when it comes to Lisp, but practice should give you the skills. Good for
you if you have both the tools and skills in your normal environments.

Zach

I could produce state even you cannot fix without resetting if I only knew
your Gödel number.

Norbert

Zach Beane wrote:
> Problematic state can happen in many systems. Resetting a system is a
> usually not necessary if you have the tools and skills needed to inspect
> and manage the system's state. You have the tools but not the skills
> when it comes to Lisp, but practice should give you the skills. Good for
> you if you have both the tools and skills in your normal environments.
>
> Zach