ReplPad Visual PARSE Debugger

[hostilefork]

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)

@hostilefork

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.

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