did you ever wish for LOAD not to abort upon encountering the first error while loading the file? To continue processign the remaining forms in the file instead?
Since both .lisp and .fas files are a successions of sexp [(loop (eval (read))], there could be a SKIP restart instead of solely the ABORT one, so as to be able to continue with the next form in the file.
In my firewall log-file analysis application, I provided two restarts when parsing .cvs files: one to stop processing this .csv file, and one to skip to the next line. What I propose here is the equivalent of the latter for LOAD.
What do people think?
[I tend to write feature requests here instead of sourceforge, so clisp-users can comment on them.]
Another approach would be a RETURN-FROM command in the debugger, to allow to shortcut the execution of a function currently on the stack with a given value. IIRC, CMUCL has this feature. CLISP only has it for EVAL frames, which are rare in compiled code.
In my logfile analysis application, I had somehow arranged for the restarts to have negligible impact on performance (hmm, maybe I finally used continuable errors instead).
From: Sam Steingold <sds@gn...> - 2004-10-14 23:53:30
> * Hoehle, Joerg-Cyril <Wbret-Plevy.Ubruyr@...> [2004-10-14 09:56:49 +0200]:
> did you ever wish for LOAD not to abort upon encountering the first
> error while loading the file? To continue processign the remaining
> forms in the file instead?
> Since both .lisp and .fas files are a successions of sexp [(loop (eval
> (read))], there could be a SKIP restart instead of solely the ABORT
> one, so as to be able to continue with the next form in the file.
I think this would require a RESTART-BIND around evaluating every single
form which, unless done by hand with load-time evaluation or something,
would be a performance killer.
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
UNIX is as friendly to you as you are to it. Windows is hostile no matter what.