Hey! I've gotten UPARSE hooked up to a debugger:
The ability to step in at every level shows just how granular the hook is. It's not a terrible lot of code:
It's barely tested, but it is public on the ReplPad if anyone wants to throw something at it.
What Concerns Did Writing This Raise?
Having the debugger in the ReplPad gives an immediate user annoyance: Why can't I type in the console while the debugger is running? (That's a huge can of worms and requires several posts of its own to talk about.)
The design of UPARSE is that you can provide your own set of combinators to use. You can give it a new WORD! combinator that does something besides fetch what the word looks up to and "act like it would if it were written there". While this simple tracing facility can handle generic interpretations, the generality could subvert the usefulness of higher level tools.
Beyond that problem of "words may not look things up at all", there's also the problem of "discovery". Everything is "discovered" as you go along--there's not a list supplied up front. That may not be a fit for some tools, so they could end up asking you to pass in the names of all the rules of interest even though they don't need to be "instrumented".
I thought of adding a BREAKPOINT combinator, so you could break in mid-parse. But I was only building up a list modeling the stack for frames while you were interacting with the buttons. Having the stack always available at an arbitrary moment would mean that the stack model would have to be updated on every call to the hook. Effectively this duplicates information held in the "real stack"--the subset of function calls that represent combinators. So it's tempting to find a way to label stack frames and enumerate them generically, vs. expecting all debuggers like this to maintain their own.
There's a lot to think about, here. But as Rebol in the browser goes, this really is the only game in town, and it's holding up pretty well whenever I exercise it!