Debugging parse.js is currently very difficult, primary for two reasons: parser construction is independent of execution and the implementation uses simulated tail calls to prevent the stack from growing too large. The first is unavoidable, but routines could be added to assist in debugging current parser state and flow.
Explicit debugging routines will be added. These will allow instrumenting and inspecting individual parsers. At least the following will be supported:
- Logging of parser results and execution state information.
- Pausing and continuing a parsing (capturing the continuation).
- Tracking relative performance and other performance metrics of a parser.
- Tracing the 'call stack' nesting of parsers.
Implementation Goals:
- Zero performance penalty on normal, non debuggable, parsers.
- Clean isolation of debug logic. No debug specific changes made to main files.
- Functional style implementation.
- Debugged parsers are transparent, i.e. they behave exactly like the original.
- Unit tests.
A separate feature for safely attaching arbitrary data to the parer state may be required as well to enable passing debug data though parsers.
Debugging parse.js is currently very difficult, primary for two reasons: parser construction is independent of execution and the implementation uses simulated tail calls to prevent the stack from growing too large. The first is unavoidable, but routines could be added to assist in debugging current parser state and flow.
Explicit debugging routines will be added. These will allow instrumenting and inspecting individual parsers. At least the following will be supported:
Implementation Goals:
A separate feature for safely attaching arbitrary data to the parer state may be required as well to enable passing debug data though parsers.