[feature] Debugger: check the parser's state

[Tartasprint]

The feature requested

I did not found a way to see what is happening about the stack in the debugger, and I think that it could be useful (and would have been in #338).
While I'm at it I would also like to check the atomicity of the parser since the rules of atomicity can get complex when nested.

I looked at the other informations of the parser's state in pest::parser_state::Parser and didn't find them to be useful in the debugger for pest user (also because I didn't dive in to understand all of them). But I think they might be useful in debugging pest itself.

Comments

I looked at how the debugger is implemented. It relies on the pest_vm::Vm and the listener proposed by the Vm.
A problem is that the listener doesn't seem to receive any information about the stack or the atomicity (which is contained by ParserState).

If this feature was implemented it would probably change the signature of the listener, and that would be a breaking change. This might be considered unimportant as a search shows no public Github repositories (except the one in this repo for the debugger) .

I do not know why only the state.position() is the only part being sent to the listener. Is there a reason for that ? If there is none, could the whole &ParserState be sent ?

[tomtau]

In general, the debugger's implementation is a bit of a hack -- off the top of my head, I don't recall if there was any special reason for a position instead a state being sent (e.g. to satisfy some trait constraints for the closures).

Anyway, one more other thing I found out is that the debugger's approach of using OS thread pausing doesn't work in a browser Wasm... so ideally it'll use a different approach, such as continuations, so having access to the parser state could be considered in that more universal implementation

[Tartasprint]

Ok, I've never worked with concurrent programs, or WASM, so I won't be able to help on the design choices that I think you are talking about.
So just passing the parser state to the listener wouldn't work ? Or making the change without rewriting the debugger is worthless ?

[tomtau]

So just passing the parser state to the listener wouldn't work ? Or making the change without rewriting the debugger is worthless ?

It could potentially work and be a small improvement for the current debugger; my comment was just that the current listener approach isn't ideal from the portability perspective