Parser debugger

[sebastienros]

I am looking for ideas on how we could provide some debug functionality on parsers. I believe that it would help the design experience to have some kind of interactive visualization of an input and output. There are many ways this could look like:

• a simple one would be to at least provide a textual representation of all the parsers that were tried and the position in the source string, using the EnterParser event. Ideally using logging such that this could be added to any existing application/parser.
• Some kind of LinqPad integration to interactively change the parser and see the output for a specific input string. Or a VS Code integration using a C# language server and two other windows for input/output.

Diagnostics could also be used to output a custom set of events that happen and could then be read with a custom app to go back and forth the parsing.

[sebastienros]

I played with EnterParser to add logging and added a Name property on Parser<T> that can be provided in the grammar. It's already quite useful, allowed me to find weird patterns in the Fluid grammar that could be optimized (in both Parlot and Fluid).

We still may need to add logging (with ILogger) so we can understand what is happening in each parser. The notion of scope could help too (add ExitParser event?) such that the output can help understand the depth of the parsing stack.

[deanmarcussen]

Playwight has the concept of traces, which write out the steps that are taken in a way that can be played back in their webapp
https://trace.playwright.dev/

It's surprisingly useful, and I could imagine a similar concept

[sebastienros]

Playwight has the concept of traces

That's a good idea, instead of focusing on how to render the output, find a well defined format that can be used in proven visualizers. Even tools doing performance analysis have flame graphs that could he used (would show the nested/stacked logic at least).

[deanmarcussen]

yes, you'd need to allow for custom (user built) parsers of course, but as long as you could keep track of the cursor, and entry / exit points you should be able to visualize (unecesary) loops, and where it's getting stuck (i.e. not finding a requested parse).

My experience with using Parlot, has tended to be, unit test everything, because so often you get stuck on why didn't it find this char