I'm getting an error but don't understand what it is telling me... can
anyone point me in the right direction? The error message in question:
Class #<STANDARD-CLASS TESTCLASS> can't be finalized because at least
one of its superclasses (#<FORWARD-REFERENCED-CLASS OBJECT>) is a
FORWARD-REFERENCED-CLASS.
[Condition of type SIMPLE-ERROR]
A more general question is if there are any existing documents for (at
least relatively common) Lisp error messages and probable causes out there?
Thanks,
Phil
In article <································@comcast.com>,
Foxpointe <·········@comcast.net> wrote:
> I'm getting an error but don't understand what it is telling me... can
> anyone point me in the right direction? The error message in question:
>
> Class #<STANDARD-CLASS TESTCLASS> can't be finalized because at least
> one of its superclasses (#<FORWARD-REFERENCED-CLASS OBJECT>) is a
> FORWARD-REFERENCED-CLASS.
> [Condition of type SIMPLE-ERROR]
The class TESTCLASS has OBJECT as one of its superclasses, but the
OBJECT class hasn't been defined yet and you tried to (make-instance
'testclass).
> A more general question is if there are any existing documents for (at
> least relatively common) Lisp error messages and probable causes out there?
Error messages are implementation-dependent, so if there are any
existing documents they would probably be the manuals or the vendor's
website.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin wrote:
> In article <································@comcast.com>,
>
> The class TESTCLASS has OBJECT as one of its superclasses, but the
> OBJECT class hasn't been defined yet and you tried to (make-instance
> 'testclass).
>
Thanks, that clarifies it for me.
>
> Error messages are implementation-dependent, so if there are any
> existing documents they would probably be the manuals or the vendor's
> website.
>
I was afraid that would be the answer.
Phil
Barry Margolin wrote:
> In article <································@comcast.com>,
> Foxpointe <·········@comcast.net> wrote:
>
>> A more general question is if there are any existing documents for (at
>> least relatively common) Lisp error messages and probable causes out there?
>
> Error messages are implementation-dependent, so if there are any
> existing documents they would probably be the manuals or the vendor's
> website.
I've built a couple of a web-based error message interpreter for Java
and C++ compilers in the past. They (1) convert error message-ese into
English novices can understand, and (2) show examples of common code
patterns that cause these errors.
They use regular expressions to scan for the critical parts, and they're
a real pain to maintain and to extend to new compilers.
So here's an AI project for people: create a database of code that
causes errors, use it to generate a database of the specific error
messages you get for different Lisps, and write a error message
retriever that can, given an error message, find the messages in the
database that are most similar to the input message.
Foxpointe wrote:
> I'm getting an error but don't understand what it is telling me... can
> anyone point me in the right direction? The error message in question:
>
> Class #<STANDARD-CLASS TESTCLASS> can't be finalized because at least
> one of its superclasses (#<FORWARD-REFERENCED-CLASS OBJECT>) is a
> FORWARD-REFERENCED-CLASS.
> [Condition of type SIMPLE-ERROR]
The good news is that you can list a superclass in defclass before the
superclass has been defined. But you do have to define the superclass
before making an instance.
btw, did you list object for a definite reason, or did you think that
was required by CLOS? If the latter you can leave the superclass list
nil and get standard-object as your superclass.
>
> A more general question is if there are any existing documents for (at
> least relatively common) Lisp error messages and probable causes out there?
fwiw, google on "forward referenced class" shows a few items down:
http://www.franz.com/support/documentation/8.0/doc/mop/concepts.html
Gotta poke around there to work out what is going on. Not a perfect
solution, but something anyway.
kt
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan
Ken Tilton wrote:
>
> The good news is that you can list a superclass in defclass before the
> superclass has been defined. But you do have to define the superclass
> before making an instance.
>
That's good to know for the future but in this instance, not what was
intended.
> btw, did you list object for a definite reason, or did you think that
> was required by CLOS? If the latter you can leave the superclass list
> nil and get standard-object as your superclass.
>
You're good... that is exactly how it got there. Object changed to nil.
>
> fwiw, google on "forward referenced class" shows a few items down:
>
> http://www.franz.com/support/documentation/8.0/doc/mop/concepts.html
>
> Gotta poke around there to work out what is going on. Not a perfect
> solution, but something anyway.
>
Thanks for the pointer.
Phil
OK, now I'm past the class problem, and have hit another error related
to list construction (a guess) which isn't clear to me. The last two
expressions calling make-test-instance (which I want to do the same
thing as the make-instance expression immediately before them) result in
a type error stating that frec/frec2 is not a list which it is.
Pointers appreciated...
(defmacro make-test-instance (class field-list)
`(make-instance ,class ,@field-list))
(defclass testclass () ((Name :initarg name) (Desc :initarg description)))
(setf rec `((Description "a description") (Name "a name")))
(setf frec (loop for x in rec
append x )) ; flatten the list
(setf frec2 `(Description "a description" Name "a name"))
; this works the way we want. The make-test-instance should be
generating for the following form
(make-instance 'testclass 'DESCRIPTION "a description" 'NAME "a name")
; neither of these works... why not?
(make-test-instance 'testclasss frec)
(make-test-instance 'testclasss frec2)
From: Ken Tilton
Subject: I would have started a new thread [was Re: Understanding Lisp error message(s)]
Date:
Message-ID: <NuKTf.2421$ud2.2194@fe09.lga>
Foxpointe wrote:
> OK, now I'm past the class problem, and have hit another error related
> to list construction (a guess) which isn't clear to me. The last two
> expressions calling make-test-instance (which I want to do the same
> thing as the make-instance expression immediately before them) result in
> a type error stating that frec/frec2 is not a list which it is.
And the most dangerous gun in the world is an unloaded one. :)
> Pointers
> appreciated...
>
> (defmacro make-test-instance (class field-list)
> `(make-instance ,class ,@field-list))
>
> (defclass testclass () ((Name :initarg name) (Desc :initarg description)))
>
> (setf rec `((Description "a description") (Name "a name")))
> (setf frec (loop for x in rec
> append x )) ; flatten the list
>
> (setf frec2 `(Description "a description" Name "a name"))
>
> ; this works the way we want. The make-test-instance should be
> generating for the following form
> (make-instance 'testclass 'DESCRIPTION "a description" 'NAME "a name")
>
> ; neither of these works... why not?
> (make-test-instance 'testclasss frec)
> (make-test-instance 'testclasss frec2)
Macros run at compile-time (driving Duane crazy). They see the source
code, not the runtime values. So make-test-instance sees the symbol
'frec. That is not a list.
Big tip: you can add diagnostic print statements to macros, outside the
code you are producing in the macro, to see what is going on. Then, when
you compile a form that invokes your macro, you will see print
diagnostics. Even before you run the code. How weird is that? Anyway...
You could check your assumption that frec is a list by putting up front
in the macro (outside the backquote):
(print (list :wtf field-list (type-of field-list))
and see at compile-time: (:wtf frec symbol)
What you want is:
`(apply 'make-instance 'testclass ,field-list)
...to get the macro to work. But that accomplishes nothing and we do not
use macros without a reason, so what you really want is not a macro:
(defun make-test-instance (field-list)
(apply 'make-instance 'test-class field-list))
kt
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan
From: Foxpointe
Subject: Re: I would have started a new thread [was Re: Understanding Lisp error message(s)]
Date:
Message-ID: <CrKdnRnrIo_qHYLZRVn-qQ@comcast.com>
Ken Tilton wrote:
> And the most dangerous gun in the world is an unloaded one. :)
>
True enough and thanks for the tip re: a new thread. Note made to do so
in the future.
> Macros run at compile-time (driving Duane crazy). They see the source
> code, not the runtime values. So make-test-instance sees the symbol
> 'frec. That is not a list.
>
First 'aha!'... I knew that they evaluated at compile-time but not that
they would attempt to do any sort of type checking (likely a direct
result of not understanding aha #2 below.)
> Big tip: you can add diagnostic print statements to macros, outside the
> code you are producing in the macro, to see what is going on. Then, when
> you compile a form that invokes your macro, you will see print
> diagnostics. Even before you run the code. How weird is that? Anyway...
>
> You could check your assumption that frec is a list by putting up front
> in the macro (outside the backquote):
>
> (print (list :wtf field-list (type-of field-list))
>
> and see at compile-time: (:wtf frec symbol)
Second 'aha!' and very helpful... I've been going nuts trying to
troubleshoot compile-time errors with my macros. I've been thinking of
macros as forms that were evaluated to produce executable code at
compile time as (somehow) being different than programs that actually
run at compile time. I think the fog is beginning to lift...
>
> What you want is:
>
> `(apply 'make-instance 'testclass ,field-list)
>
> ...to get the macro to work. But that accomplishes nothing and we do not
> use macros without a reason, so what you really want is not a macro:
>
Actually, I was going for `(apply 'make-instance 'testclass
,@field-list) to 'flatten' the list into arguments for make-instance.
But if I'm following, I think I get it... let's see if I really do:
because the macro sees field-list as a symbol and not a list. (i.e. even
though what is passed is actually a list, it is 'spliced' in since the
compiler only sees the symbol?) Also, the function below doesn't need
the list 'flattened' for the same reason?
> (defun make-test-instance (field-list)
> (apply 'make-instance 'test-class field-list))
>
Phil
From: Ken Tilton
Subject: Re: I would have started a new thread [was Re: Understanding Lisp error message(s)]
Date:
Message-ID: <%_NTf.2553$ud2.1309@fe09.lga>
Foxpointe wrote:
> Ken Tilton wrote:
>
>> And the most dangerous gun in the world is an unloaded one. :)
>>
>
> True enough and thanks for the tip re: a new thread. Note made to do so
> in the future.
>
>> Macros run at compile-time (driving Duane crazy). They see the source
>> code, not the runtime values. So make-test-instance sees the symbol
>> 'frec. That is not a list.
>>
>
> First 'aha!'... I knew that they evaluated at compile-time but not that
> they would attempt to do any sort of type checking...
Well, no, you coded:
,@field-list
It is not /macros/ are doing type-checking, it is the operator @.
(likely a direct
> result of not understanding aha #2 below.)
>
>> Big tip: you can add diagnostic print statements to macros, outside
>> the code you are producing in the macro, to see what is going on.
>> Then, when you compile a form that invokes your macro, you will see
>> print diagnostics. Even before you run the code. How weird is that?
>> Anyway...
>>
>> You could check your assumption that frec is a list by putting up
>> front in the macro (outside the backquote):
>>
>> (print (list :wtf field-list (type-of field-list))
>>
>> and see at compile-time: (:wtf frec symbol)
>
>
> Second 'aha!' and very helpful... I've been going nuts trying to
> troubleshoot compile-time errors with my macros. I've been thinking of
> macros as forms that were evaluated to produce executable code at
> compile time as (somehow) being different than programs that actually
> run at compile time.
Right. That is the beauty of CL macros, you write (arbitrarily complex)
familiar CL to "write" the boilerplate code you want to avoid typing in
by hand again and again. When invoked, one supplies just the beef. (So
it is funny that the anti-macro crowd argue that macros make code harder
to follow.)
> I think the fog is beginning to lift...
>
>>
>> What you want is:
>>
>> `(apply 'make-instance 'testclass ,field-list)
>>
>> ...to get the macro to work. But that accomplishes nothing and we do
>> not use macros without a reason, so what you really want is not a macro:
>>
>
> Actually, I was going for `(apply 'make-instance 'testclass
> ,@field-list) to 'flatten' the list into arguments for make-instance.
> But if I'm following, I think I get it... let's see if I really do:
> because the macro sees field-list as a symbol and not a list. (i.e. even
> though what is passed is actually a list, it is 'spliced' in since the
> compiler only sees the symbol?)
You lost me, probably over differing understandings of "spliced in". i
thought you were going to say "it /cannot/ be spliced in since the
/macro/ only sees the symbol". The list will not even exist until runtime.
> Also, the function below doesn't need
> the list 'flattened' for the same reason?
No, here the trick is that apply does exactly what you had in mind,
without requiring any expanding @ operator, but only on the last
argument to apply (whereas within a backquote I can @ any number of
variables to splice in the lists to which they are bound). Apply is a
hard-coded splicer.
>
>> (defun make-test-instance (field-list)
>> (apply 'make-instance 'test-class field-list))
Yep. Now maybe this will help: when /do/ you get to use @field-list?
Here is how I build part of a GUI demo:
(mk-row (:borderwidth 2 :relief 'sunken)
(mk-label :text "Rotation:")
(mk-button-ex ("Start" (setf (running (fm^ :moire-1)) t)))
(mk-button-ex ("Stop" (setf (running (fm^ :moire-1)) nil)))
(mk-button-ex ("Hallo" (format T "Hallo~%")))
(mk-button-ex ("Welt!" (format T "Welt~%"))))
That expands to:
(make-instance 'ctk::frame-row
:fm-parent *parent*
:borderwidth 2
:relief 'sunken
:kids (c? (the-kids
(mk-label :text "rotation:")
(mk-button-ex ..)
(mk-button-ex ...)
(mk-button-ex ("hallo" (format t "hallo~%")))
(mk-button-ex ("welt!" (format t "welt~%"))))))
The macro would be (somewhat edited and wholly untested since then):
(defmacro mk-row ((&rest initargs) &rest kids)
`(make-instance 'frame-row
:fm-parent *parent*
,@initargs
:kids (c? (the-kids ,@kids)))))
The idea (going back to the actual inline usage of the macro) is to
allow the programmer (a) to code as many initargs and (b) as many kids
as they like just by typing them vs cobbling them together into a list
to be passed to a function. Plus i am supplying various bits of
boilerplate such as ":kids (c? (the-kids...".
Now when we allow the programmer to type an arbitrarily long list of
things instead of first pulling them into a list and passing that one
thing to a function, we need a &rest arg. I have two above. But once we
have a rest arg in a macro, we have a problem. I could not just say, eg:
`(make-instance 'frame-row :kids ,kids)
That would expand to (abbreviated):
(make-instance 'frame-row :kids ((make-kid1)(make-kid2)))
Then I get an error that (make-kid1) is not the name of a function or
macro or special form. I cannot quote the list because I need each
(make-xxx) evaluated, not just as a list of one symbol 'make-xxx. Which
is why we have @. And I cannot just say :kids ,@kids, because then I get:
(make-instance 'frame-row :kids (make-kid1)(make-kid2))
Look closely and you will see (make-kid2) is just dangling out there
unpaired with any initarg (:kids went with (make-kid1)) so I get an "odd
number of initargs" or somesuch error.
I would have to say :kids (list ,@kids), expansion thereof left as an
exercise.
hth.
ken
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan
From: Ken Tilton
Subject: Re: I would have started a new thread [was Re: Understanding Lisp error message(s)]
Date:
Message-ID: <TeOTf.2554$ud2.1311@fe09.lga>
A clarification....
Foxpointe wrote:
> Also, the function below doesn't need
> the list 'flattened' for the same reason?
>
>> (defun make-test-instance (field-list)
>> (apply 'make-instance 'test-class field-list))
In this case, the functions make-test-instance and apply never see the
symbol field-list! They only see the runtime list value that had better
be passed to make-test-instance.
The trick with writing macros is to keep clearly separate in your mind
compile time vs run time, and to remember that outside the backquotes
you are in compile time and just manipulating source code, inside the
backquote you should be thinking about runtime and the values that will
be bound to different variables then.
Again, the debugging statements outside the backquotes will help you get
used to thinking about compile time.
kt
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan
Ken Tilton wrote:
> A clarification....
>
> Foxpointe wrote:
>> Also, the function below doesn't need the list 'flattened' for the
>> same reason?
>>
>>> (defun make-test-instance (field-list)
>>> (apply 'make-instance 'test-class field-list))
>
> In this case, the functions make-test-instance and apply never see the
> symbol field-list! They only see the runtime list value that had better
> be passed to make-test-instance.
>
> The trick with writing macros is to keep clearly separate in your mind
> compile time vs run time, and to remember that outside the backquotes
> you are in compile time and just manipulating source code, inside the
> backquote you should be thinking about runtime and the values that will
> be bound to different variables then.
>
> Again, the debugging statements outside the backquotes will help you get
> used to thinking about compile time.
>
> kt
>
I appreciate you and Pascal taking the time to provide further
clarification. In addition to understanding more about macros and apply
(now I know what spreadable argument list designators are), it's
becoming clear that I will continue to learn Lisp as an ongoing exercise
into the foreseeable future ;-)
Thanks,
Phil
Foxpointe <·········@comcast.net> writes:
> Ken Tilton wrote:
>[...]
>> What you want is:
>> `(apply 'make-instance 'testclass ,field-list)
>> ...to get the macro to work. But that accomplishes nothing and we do
>> not use macros without a reason, so what you really want is not a
>> macro:
>>
>
> Actually, I was going for `(apply 'make-instance 'testclass
> ,@field-list) to 'flatten' the list into arguments for
> make-instance. But if I'm following, I think I get it... let's see if
> I really do: because the macro sees field-list as a symbol and not a
> list. (i.e. even though what is passed is actually a list, it is
> spliced' in since the compiler only sees the symbol?) Also, the
> function below doesn't need the list 'flattened' for the same reason?
>
>> (defun make-test-instance (field-list)
>> (apply 'make-instance 'test-class field-list))
No that's not it. Read CLHS apply
APPLY takes a number of arguments, of which the last must be a list of
remaining arguments.
(let ((field-list '(a b c)))
`(apply 'make-instance 'testclass ,@field-list))
--> (apply (quote make-instance) (quote testclass) a b c)
Is c bound to a list? I guess not. So you want this:
(let ((field-list '(a b c)))
`(apply 'make-instance 'testclass ',field-list))
--> (apply (quote make-instance) (quote testclass) (quote (a b c)))
or this:
(let ((field-list '(a b c)))
`(apply 'make-instance 'testclass (list ,@field-list)))
--> (apply (quote make-instance) (quote testclass) (list a b c))
or this:
(let ((field-list '(a b c)))
`(apply 'make-instance 'testclass ,@field-list nil))
--> (apply (quote make-instance) (quote testclass) a b c nil)
The last two being equivalent (the same values are passed as argument
to make-instance).
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
Pascal Bourguignon wrote:
> Foxpointe <·········@comcast.net> writes:
>
>
>>Ken Tilton wrote:
>>[...]
>>
>>>What you want is:
>>> `(apply 'make-instance 'testclass ,field-list)
>>>...to get the macro to work. But that accomplishes nothing and we do
>>>not use macros without a reason, so what you really want is not a
>>>macro:
>>>
>>
>>Actually, I was going for `(apply 'make-instance 'testclass
>>,@field-list) to 'flatten' the list into arguments for
>>make-instance. But if I'm following, I think I get it... let's see if
>>I really do: because the macro sees field-list as a symbol and not a
>>list. (i.e. even though what is passed is actually a list, it is
>>spliced' in since the compiler only sees the symbol?) Also, the
>>function below doesn't need the list 'flattened' for the same reason?
>>
>>
>>>(defun make-test-instance (field-list)
>>> (apply 'make-instance 'test-class field-list))
>
>
> No that's not it.
I think you missed that in the middle of everything I snuck in a
suggestion that the OP switch to a function since the macro served no
good end.
kt
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan