Prev: the rise and fall of t
Next: emacs lisp tutorial: Count Words and Chars
From: Alan Malloy on 24 Mar 2010 06:59
As mentioned earlier, I'm a new Lisper (and taking up emacs as well now;
thanks refun for re-suggesting it). I was trying to write a simple macro
earlier tonight, and I'd written a long post to ask c.l.lisp to help me
figure out what was wrong. But, afraid of looking too much like a
newcomer, I spent an additional hour or two trying to understand what
was happening and finally figured it out (so that's good, I guess). My
question NOW is, does anyone have a reference, or even some general
tips, on how to understand compiler/interpreter error messages?

Tonight's message was "EVAL: #1=(SETF #:G3813 NIL) is not a function
name; try using a symbol instead", and it took me forever to understand
that I was misusing backquote as `((setf ,var nil) (more stuff) when
what I really meant was `(progn (setf ,var nil) (more stuff). I've had
lots of experiences like this in my week-long Lisp career already, and I
hope that someone out there can tell me how to understand the compiler's
feedback. If it matters, I'm using clisp 2.44 and emacs. Usually I use
slime too, but the error messages it generates are even more obscure so
I often fall back on entering stuff into clisp by hand.

--
Cheers,
Alan (San Jose, California, USA)
From: Zach Beane on 24 Mar 2010 07:14
Alan Malloy <alan.NO.SPAM(a)malloys.org> writes:

> As mentioned earlier, I'm a new Lisper (and taking up emacs as well
> now; thanks refun for re-suggesting it). I was trying to write a
> simple macro earlier tonight, and I'd written a long post to ask
> c.l.lisp to help me figure out what was wrong. But, afraid of looking
> too much like a newcomer, I spent an additional hour or two trying to
> understand what was happening and finally figured it out (so that's
> good, I guess). My question NOW is, does anyone have a reference, or
> even some general tips, on how to understand compiler/interpreter
> error messages?

Practice? The error message below immediately made me think "There's a
bogus form that looks like ((setf ... nil) ...) somewhere." Maybe that's
a matter of seeing similar errors like that in the past, and
understanding the evaluations rules?

> Tonight's message was "EVAL: #1=(SETF #:G3813 NIL) is not a function
> name; try using a symbol instead", and it took me forever to
> understand that I was misusing backquote as `((setf ,var nil) (more
> stuff) when what I really meant was `(progn (setf ,var nil) (more
> stuff).

Practice will help with that, too.

Zach
From: Nicolas Neuss on 24 Mar 2010 07:56
Alan Malloy <alan.NO.SPAM(a)malloys.org> writes:

> Tonight's message was "EVAL: #1=(SETF #:G3813 NIL) is not a function name;
> try using a symbol instead", and it took me forever to understand that I
> was misusing backquote as `((setf ,var nil) (more stuff) when what I really
> meant was `(progn (setf ,var nil) (more stuff).

As a Lisp newcomer you should probably just forget about backquote and
follow some introductory examples first. Which book do you use?

Nicolas
From: Tamas K Papp on 24 Mar 2010 08:07
On Wed, 24 Mar 2010 03:59:17 -0700, Alan Malloy wrote:

> As mentioned earlier, I'm a new Lisper (and taking up emacs as well now;
> thanks refun for re-suggesting it). I was trying to write a simple macro
> earlier tonight, and I'd written a long post to ask c.l.lisp to help me
> figure out what was wrong. But, afraid of looking too much like a
> newcomer, I spent an additional hour or two trying to understand what
> was happening and finally figured it out (so that's good, I guess). My
> question NOW is, does anyone have a reference, or even some general
> tips, on how to understand compiler/interpreter error messages?

Generally, practice is the only thing that will help you.

> Tonight's message was "EVAL: #1=(SETF #:G3813 NIL) is not a function
> name; try using a symbol instead", and it took me forever to understand
> that I was misusing backquote as `((setf ,var nil) (more stuff) when
> what I really meant was `(progn (setf ,var nil) (more stuff). I've had
> lots of experiences like this in my week-long Lisp career already, and I
> hope that someone out there can tell me how to understand the compiler's
> feedback. If it matters, I'm using clisp 2.44 and emacs. Usually I use
> slime too, but the error messages it generates are even more obscure so
> I often fall back on entering stuff into clisp by hand.

CL (and SLIME) have a lot of debugging facilities, and you may want to
explore them. There have been various threads on c.l.l about these,
search the archives.

I found this talk especially useful:
http://common-lisp.net/~trittweiler/talks/slime-talk-2008.pdf
(especially the inspector/debugger part)

I don't know how relevant this is to Clisp, but optimization
declarations affect your debugging experience on some implementations
rather heavily. Eg in SBCL, sometimes you need to compile with
(declaim (optimize (debug 3))) because SBCL will optimize away a lot
of things.

Tamas
From: Alex Mizrahi on 24 Mar 2010 10:27
AM> was happening and finally figured it out (so that's good, I guess). My
AM> question NOW is, does anyone have a reference, or even some general
AM> tips, on how to understand compiler/interpreter error messages?

1. Of course, practice helps a lot.
2. Different implementations have different error messages, some might be
more informative than the other. I don't know which is the best, but if you
have particularly hard error, it might make sense to try in a different
implementation(s) -- maybe rephrased error message will be easier to
understand, or you can see something common, etc.
I've heard commercial implementation have cool debuggers with stepping
and stuff, but I've never used them myself...
3. I know it is hard to believe that, but often _attentive_ reading of error
messages and documentation helps. If you don't know some concepts references
in the error message, look them up in documentation.
4. Googling for some part of an error message might show messages of people
having same error and, possibly, resolution. A trick is to pick a relevant
part of the message, omitting unnecessary details.
5. If you're looking for a quick fix, try asking on IRC channel (#lisp on
irc.freenode.net). People are wasting time on IRC anyway, so it is not a
problem to ask even dumb questions.

6. If you're debugging macros, there are some tricks:
* macroexpand it (duh!)
* if you have problems only in certain context, or if you're debugging
macrolet, macroexpand and print it _in that conext_.
there is a magic macro for it:

(defmacro mx1p (form &environment env)
"Macroexpands form in context and prints it in macroexpansion time.
Otherwise transparent"
(print (macroexpand-1 form env))
form)

E.g. if you want to expansion of (foo 42) here:

(macrolet ((foo (x) `(bar ,x)))
(foo 42))

Just wrap it with mx1p:


(macrolet ((foo (x) `(bar ,x)))
(mx1p (foo 42)))

It prints (BAR 42) when you compile this.

AM> Tonight's message was "EVAL: #1=(SETF #:G3813 NIL) is not a function
AM> name; try using a symbol instead",

Well, it's rather simple. Where is function name used? In a function call.
It usually looks like (function_name function parameters).
And indeed, it is usually a symbol. What it tells you is that you have (SETF
something) instead of function name. That is, you have ((setf ...) function
parameters).
Quite a weird form...
Where do you have SETF in your macro? Can it generate this weird function
call? How it should look?

LIkewise, you could use macroexpansion to see that `((setf ...) (more
stuff)) looks weird.
If it doesn't, then maybe you need to read a chapter about semantics of
evaluation in Common Lisp.


 |  Next  |  Last
Pages: 1 2 3
Prev: the rise and fall of t
Next: emacs lisp tutorial: Count Words and Chars