In my recent dabblings with Common Lisp, I've noticed that simple
mispellings of symbols seem to be not always easy to catch, as they would
be with C, for example. For example, I just spent 10 minutes debugging an
unbound-variable message, only to find out that I had mispelled it in the
let-binding. Is this just due to my lack of experience with lisp? Does
this get easier with time? In C, mis-spelled variables are trivial to find
and fix (a matter of seconds), while with Lisp, I am finding that I often
need many minutes to find these problems. I imagine that the
difficulty is that Lisp is a dynamic language, whereas with C, symbol
references are always static, and hence are trivial to debug.
Well, in any case, I'm not writing to flame Lisp, but to ask for guidance
in
how to troubleshoot these cases a little faster.
Larry
--
-- Larry Troxler -- ··@westnet.com -- Patterson, NY USA --
In article <············@mycroft.westnet.com>,
Lawrence Troxler <··@westnet.com> wrote:
>In my recent dabblings with Common Lisp, I've noticed that simple
>mispellings of symbols seem to be not always easy to catch, as they would
>be with C, for example. For example, I just spent 10 minutes debugging an
>unbound-variable message, only to find out that I had mispelled it in the
>let-binding. Is this just due to my lack of experience with lisp? Does
>this get easier with time? In C, mis-spelled variables are trivial to find
>and fix (a matter of seconds), while with Lisp, I am finding that I often
>need many minutes to find these problems. I imagine that the
>difficulty is that Lisp is a dynamic language, whereas with C, symbol
>references are always static, and hence are trivial to debug.
Could you give an example of the kinds of mistakes you're running into?
Most variable misspelling will won't result in a warning from good
compilers. For instance, if you do:
(defun broken-function (varible)
(print variable))
you should get two warnings: one that VARIBLE is bound but never used, and
another that VARIABLE is being presumed SPECIAL. Or if you do:
(defun my-print (thing half-radix)
(let ((*print-bas* (* half-radix 2)))
(print thing)))
you should get a warning that *PRINT-BAS* is bound but not used.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>
Please don't send technical questions directly to me, post them to newsgroups.
In article <············@mycroft.westnet.com> Lawrence Troxler
<··@westnet.com> writes:
>
> In my recent dabblings with Common Lisp, I've noticed that simple
> mispellings of symbols seem to be not always easy to catch, as they would
> be with C, for example. For example, I just spent 10 minutes debugging an
> unbound-variable message, only to find out that I had mispelled it in the
> let-binding. Is this just due to my lack of experience with lisp? Does
> this get easier with time? In C, mis-spelled variables are trivial to find
> and fix (a matter of seconds), while with Lisp, I am finding that I often
> need many minutes to find these problems. I imagine that the
> difficulty is that Lisp is a dynamic language, whereas with C, symbol
> references are always static, and hence are trivial to debug.
>
> Well, in any case, I'm not writing to flame Lisp, but to ask for guidance
> in
> how to troubleshoot these cases a little faster.
>
> Larry
>
You are probably comparing apples to organges. That is to say I suspect
that you are running the Lisp code with the Lisp interpreter and of course
with C code you *must* compile it. The C compiler serves as a batch code
analyzer. If you compile the Lisp code most good Lisp compilers will give
you warnings. For example if we intentionally misspell a variable in a
program using Allegro CL
(defun faa (x) (let ((cay 5)) (+ x cat)))
FAA
First interpreted
(faa 5)
Error: Attempt to take the value of the unbound symbol CAT
then compile (more like C)
(compile 'faa)
Warning: Symbol CAT declared special
Warning: variable CAY is never used
In many Common Lisps you can also turn on/off various kinds of compiler
warnings. See your CL manual. There are also tools for automating the
recompiling of Lisp functions that change, code analysis tools and Emacs
Lisp shells that help with debugging. See the Lisp FAQ.
Also note that if you are an Emacs user there are tools for eliminating
misspellings. A very simple one is DABBREV-EXPAND bound to M-/, which not
only helps spell a previously typed variable the same way but even
eliminates having to retype it.
Your intuition is partially correct in that Lisp being a dynamic language is
related to "run time surprises", however many of us who program in both C
and Lisp feel that the benefits of a dynamic language far outweigh the
uncertainty of "run time surprises". Furthermore when one starts writing C
and C++ programs that needs to create and delete complex run time data, one
still gets "run time surprises", only they are frequently harder to debug
than in Lisp and in some sense more fatal. In Common Lisp there are clean
ways of dealing with "run time surprises" programmatically using the Common
Lisp *condition system*.
I guarantee you that after you learn Lisp and the Lisp development tools
well, your overall development time will be dramatically reduced over
development time using C even if you are expert with GDB. The problem of
misspelled variables should become negligible.
--
William P. Vrotney - ·······@netcom.com
For the (LMI) Lisp machine, one of us (Pace or I) wrote a package DWIM
to deal with misspelled symbols. Rather than interning the new
symbol, it did a quick search for similar symbol names within the
package and offered a proceed option to use that one instead.
Lawrence Troxler wrote:
>
> In my recent dabblings with Common Lisp, I've noticed that simple
> mispellings of symbols seem to be not always easy to catch, as they would
> be with C, for example. For example, I just spent 10 minutes debugging an
> unbound-variable message, only to find out that I had mispelled it in the
> let-binding. Is this just due to my lack of experience with lisp? Does
> this get easier with time?
It might be just lack of experience, though I am not sure I follow your
example. Can you post some erroneous code that stumped you for a while?
My compiler (Mac Common Lisp) tells me if I misspell an lvar or function
argument (and even if I do not /use/ one, which might mean I referred to
a valid variable when I meant to refer to something else). If I code:
(let ((iten (find-item ....)))
(format t "The item is ~s" item))
...my compiler squawks about "item", same as in C (except when I hit
Enter, not when I compile the entire source file. <g> Did you not get a
message until runtime?
My bottom line answer is I have written a ton of C and do appreciate the
language, but (1) Lisp is not harder to debug than C in any way, (2) it
is easier to debug in many ways.
Just thought of one C debugging advantage: source debugging. But I do
not like source debugging except for certain kinds of bugs.
Cheers,
Ken
In article <·············@bway.net>, ····@bway.net wrote:
> My compiler (Mac Common Lisp) tells me if I misspell an lvar or function
> argument (and even if I do not /use/ one, which might mean I referred to
> a valid variable when I meant to refer to something else). If I code:
>
> (let ((iten (find-item ....)))
> (format t "The item is ~s" item))
>
> ...my compiler squawks about "item", same as in C (except when I hit
> Enter, not when I compile the entire source file. <g> Did you not get a
> message until runtime?
For me it works even when I hit enter.
;Compiler warnings :
; Undeclared free variable ITEM, in an anonymous lambda form.
; Unused lexical variable ITEN, in an anonymous lambda form.
> Error: Unbound variable: ITEM
> My bottom line answer is I have written a ton of C and do appreciate the
> language, but (1) Lisp is not harder to debug than C in any way,
Sounds like a C problem
> (2) it
> is easier to debug in many ways.
Hmm, Common Lisp code with Macros or Macros generating Macros
is notoriously difficult to debug. Often you don't have an
idea what generated your code or what your current stack frame
corresponds to. Without a good idea about Common Lisp and
the application it is completely unthinkable to debug some
of the advanced programs. There is no real chance for
source line debugging.
--
http://www.lavielle.com/~joswig/
* Rainer Joswig
| Hmm, Common Lisp code with Macros or Macros generating Macros is
| notoriously difficult to debug. Often you don't have an idea what
| generated your code or what your current stack frame corresponds to.
| Without a good idea about Common Lisp and the application it is
| completely unthinkable to debug some of the advanced programs. There is
| no real chance for source line debugging.
I would have thought that an (optimize (debug 3)) declaration in effect
would have made such information available even in a compile-only Common
Lisp, but I think I prefer having an interpreter available when debugging,
although there is still a problem when running macro expansion functions.
`step' is source line debugging for me.
the only time I have missed source line debugging is when finding the rare
compiler bug, not when finding my own bugs.
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://www.naggum.no/emacs/ for Emacs-20-related material.
In article <················@naggum.no>, Erik Naggum <······@naggum.no> wrote:
> * Rainer Joswig
> | Hmm, Common Lisp code with Macros or Macros generating Macros is
> | notoriously difficult to debug. Often you don't have an idea what
> | generated your code or what your current stack frame corresponds to.
> | Without a good idea about Common Lisp and the application it is
> | completely unthinkable to debug some of the advanced programs. There is
> | no real chance for source line debugging.
>
> I would have thought that an (optimize (debug 3)) declaration in effect
> would have made such information available even in a compile-only Common
> Lisp,
Why that? It would still macro expand. You would still need in
most cases to give the Lisp system directives to record necessary debugging
information (who calls, local symbols, symbols in fasls, source
file recording, ...) before compiling. Change a macro or an
inlined function - does your Lisp system give a list of what to recompile?
> but I think I prefer having an interpreter available when debugging,
If the code you want debug is locally understandable. Once
you have 30000+ lines you won't know what to compile and
what not.
> although there is still a problem when running macro expansion functions.
> `step' is source line debugging for me.
Sometimes stepping is not possible. I just ran across a problem
that makes it impossible for me to step such code (reason: only
optimized compiled code is valid, the interpreter complains).
> the only time I have missed source line debugging is when finding the rare
> compiler bug, not when finding my own bugs.
I can live without it. But this is only for experts.
Sometimes I wish library developers would deliver regression
test cases and special debugging options (special error handlers,
ready made trace configurations, logging mechanisms, event replay,
copy stream output to debugging streams, explanations
for the selection of effective methods, useful error conditions,
uninlining, assertions, ...).
--
http://www.lavielle.com/~joswig/
On Fri, Oct 10, 1997 6:33 PM, Lawrence Troxler <·········@westnet.com>
wrote:
>In my recent dabblings with Common Lisp, I've noticed that simple
>mispellings of symbols seem to be not always easy to catch, as they would
>be with C, for example. For example, I just spent 10 minutes debugging an
>unbound-variable message, only to find out that I had mispelled it in the
>let-binding. Is this just due to my lack of experience with lisp? Does
>this get easier with time? In C, mis-spelled variables are trivial to find
>and fix (a matter of seconds), while with Lisp, I am finding that I often
>need many minutes to find these problems. I imagine that the
>difficulty is that Lisp is a dynamic language, whereas with C, symbol
>references are always static, and hence are trivial to debug.
>
>Well, in any case, I'm not writing to flame Lisp, but to ask for guidance
>in
>how to troubleshoot these cases a little faster.
>
You may be able to coax some more informative messages out of your compiler
(what is it, BTW?) by evaluating this at the start of your session:
(declaim (optimize (debug 3) (safety 3) (compilation-speed 0))
Dave
From: ? the platypus {aka David Formosa}
Subject: Re: Debugging mispellings?
Date:
Message-ID: <876739025.836885@cabal>
In <············@mycroft.westnet.com> Lawrence Troxler <··@westnet.com> writes:
>In my recent dabblings with Common Lisp, I've noticed that simple
>mispellings of symbols seem to be not always easy to catch, as they would
>be with C, for example.
Partly this is because of your lack of exprence with lisp. I tend
(because of my condtion) to add meany meany spelling errors and have had
no great problem tracking them down.
Hopefully with a bit more exprence your will be able to trace down
spelling errors with the best of them.
> For example, I just spent 10 minutes debugging an
>unbound-variable message, only to find out that I had mispelled it in the
>let-binding.
This is a typicl problem annd would have been the first thing that I would
have looked out. Don't worry we all had these problems when we started.
--
Please excuse my spelling as I suffer from agraphia see the url in my header.
Never trust a country with more peaple then sheep. Buy easter bilbies.
Save the ABC Is $0.08 per day too much to pay? ex-net.scum and proud
I'm sorry but I just don't consider 'because its yucky' a convincing argument