I'm writing a little interactive DSL for my application, which looks a
big like the REPL util in Norvig's book, chapter 6. It has syntax and
isn't S-expr-based (let's not debate this - I love S-exprs, but my DSL
won't use them). So I implemented my own READ function.
However, there is a problem with the debugger. My DSL is *not*
interpeted - it's compiled (to Lisp), so I can't just implement my own
debugger (because I don't implement my own runtime). I don't want to
simply quit if an error occurs either (like Norvig's util). OTOH, I
don't want my users (who might not even consider themselves
"programmers") to be exposed to the CMUCL debugger directly (Or I'll
get crucified like that guy in the movie)
So, I want complete control over the debugger: replacing its READ,
PRINT, help messages, etc. (you get the picture hopefully - that's why
I provided the context). How can this be done in CMUCL? (I've read
about the condition system and debugger related material in the
hyperspec, and I don't think what I want can be done in CL proper)
·············@yahoo.com (David Fisher) writes:
> So, I want complete control over the debugger: replacing its READ,
> PRINT, help messages, etc. (you get the picture hopefully - that's why
> I provided the context). How can this be done in CMUCL? (I've read
> about the condition system and debugger related material in the
> hyperspec, and I don't think what I want can be done in CL proper)
You could look at how we do it in SLIME. Since we use our own debugger
witha whole lot of Lisps we have some well-defined "debugging
primitives", with implementations for most systems (including CMUCL).
The interface defininition file (search for "Debugging") is at:
http://www.common-lisp.net/cgi-bin/viewcvs.cgi/slime/swank-backend.lisp?rev=HEAD&cvsroot=slime&content-type=text/vnd.viewcvs-markup
The implementation for CMUCL is at:
http://www.common-lisp.net/cgi-bin/viewcvs.cgi/slime/swank-cmucl.lisp?rev=HEAD&cvsroot=slime&content-type=text/vnd.viewcvs-markup
The CMUCL manual does cover the "debug-internals" interface, but it's
tricky to get the hang of. If you're lucky you could just call our
`swank-backend' package directly.
Cheers,
Luke