ReplPad Visual PARSE Debugger

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:

replpad-js/eparse.reb at eb8a62054d345f798b3b87364943df3534a7b92e · hostilefork/replpad-js · GitHub

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!

2 Likes

Bravo ! Nicely done !

Great video. A pity I will not be able to watch it (again) because of YT's crusade against ad-blockers. I stopped using YT and started to boycot its advertisers and gave them notice of why I returned my orders.

This UPARSE debugging demo (which thankfully still runs, in 2026) was based on the idea that every combinator exposed a hook before it ran.

This hook let you take control of the parser's behavior--a bit like you had an ENCLOSE implicitly running on each one. That hook also had access to rule-start and rule-end properties, which were available if the FRAME! for the parser had been built by a compatible combinating agent (e.g. the BLOCK! combinator)

So on the one hand: this idea of "patching" a stack structure on each step seems a dead end for generalized debugging.

I mention at least one problem: which is that you can only trace from the very beginning of the parse down to some "depth of interest". There's no way to suddenly "break into the debugger" and actualize the stack to look at it.

On the other hand: I think my instincts are right that you should be able to theoretically build a stack-accurate model this way. The event model should be complete enough that you are made aware of everything that you could want to know through events... for the purposes of implementing logging or breakpoints. It's just that the stack tool itself shouldn't be based on this.

Going deeper on this at another thread:

https://rebol.metaeducation.com/t/debugger-events-vs-stack-walking/2699