RE: LispWorks REPL Errors
Hi Mikel,
That is actually pretty darn cool! I am going to make an attempt to do exactly what you are describing as "just-in time programming". It just sounds like good clean fun ;-)
Thanks,
Gerry
-----Original Message-----
From: mikel evins [mailto:mevins@clozure.com]
Sent: Sunday, February 17, 2013 5:25 PM
To: Gerry Weaver
Cc: mikel evins; Jeffrey Massung; lisp-hug@lispworks.com
Subject: Re: LispWorks REPL Errors
On Feb 17, 2013, at 5:06 PM, Gerry Weaver <gerryw@compvia.com> wrote:
> Hi Jeffrey,
>
> I don't mind "a little nudge" at all. I think your recommendation makes perfect sense. I guess I am so used to the C/C++ world that I failed to consider the differences between the languages. In C/C++ I only use a debugger to get the call stack trace before a segfault. Otherwise, I never use one at all. Lisp on the other hand is a different animal. I should slow down and try harder not to let old habits get the better of me. I have also noticed that there is a fair amount of Lisp code out there that doesn't do any error handling at all. I already have a big bold item on my todo list for getting comfortable with Lisp error handling. It all needs to be done and that would be a much better way to approach it. Thanks for the nudge ;-)
There's a different style of debugging to learn. There's nothing wrong with looking at stack traces, or with printf debugging, and you still have those available to you in Lisp. However, you have some additional tools in Lisp that are pretty handy, and that you're unlikely to be aware of if you haven't used a language that provides them, like Lisp or Smalltalk.
The REPL stops in a break loop so that you can examine the live stack--not the way you would examine a C stack trace, where the computation is over and the stack trace is a fossil record, but while the computation is still live and pending. In a break loop you can look at the state of the live machine, paused between instructions. You can look and see if the values in the lexically-visible variables are what you expect them to be. If they're not, you can interactively change them and resume the computation, to confirm whether fixing the difference ends in correct results. You can even redefine offending functions and then restart.
These facilities make a whole different style of programming available. You can write just the top-level entry point and run it. Of course, it's going to break, but when you land in the break loop you can write the next functions you need and resume. When you hit another break loop, you can write the next functions, and so on. It's kind of a logical extreme of test-driven development--where you really having nothng when you start but the notion of what goals you want the program to satisfy. It's just-in-time programming--not, maybe, the way you want to work all the time, but a handy option to have. It offers the opportunity to follow a thought all the way to its logical conclusion with live code, while all the context is fresh in your mind.
_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html