Development "Mode"

[bd82]

As the name implies, a Dev mode should help during the development of Chevrotain Grammars.
Examples:

• Runtime type checks for the DSL methods arguments.
  • especially constructor arguments (example: Support MultiMode Lexer definitions in Parser Constructor. #395)
  • Can also try checking that in CST Mode no parser rule ever returns a user defined value.
• Grammar Tracing.
• Performance Tracing.
• Tracing of parser initialization phases, to help detect "location" of slow initializations.
• Print parser configuration on initialization.
• Tracing lexer Modes transitions (Lexing mode stack vs a state machine (how to implement alternating modes) #597 (comment))

[bd82]

Runtime type checks should be pretty simple to implement using NO-OP pattern.

[CMCDragonkai]

Also wanted to mention that I don't think the library should alert the user about: Running the Lexer in Debug Mode, DO NOT ENABLE THIS IN PRODUCTIVE ENV!. Sometimes you need "debug" mode even in production because the production application itself is an exercise in lexing. It should just be in the documentation.

[CMCDragonkai]

Another suggestion, sometimes you want to actually see the skipped tokens. I propose that the debug mode shows the skipped tokens as well. This way you can ensure that skipped tokens are being skipped properly.

[bd82]

Another suggestion, sometimes you want to actually see the skipped tokens. I propose that the debug mode shows the skipped tokens as well. This way you can ensure that skipped tokens are being skipped properly.

Thanks, it is a good suggestion, it is already possible to do this manually
by changing the group from 'Lexer.SKIPPED' to some named group.

See example of Token Groups.
https://github.com/SAP/chevrotain/blob/master/examples/lexer/token_groups/token_groups.js

[CMCDragonkai]

I see, by changing the groups, you can then later filter the token vector by groups.

One more suggestion, the diagram creation examples all work on parsers, what about diagram creation for the lexers? https://github.com/JexCheng/regulex

[bd82]

Diagrams for regExps look nice.
Perhaps they can be integrated into the existing diagrams as tooltips/popups.

The more interensting potential of a library like regulex is more in depth analysis of the lexer.
See #525

[bd82]

I don't think this issue is still relevant.

• I never found tracing to be too needful because it is so easy to just debug.

  • But there is still an issue open for some scope of this Debug Tools - Grammar runtime tracing #834.

• Runtime checks can be replaced with using TypeScript to check JavaScript code with the provided type definitions of chevrotain.

One thing that is still very relevant is #874 - a debug helper method to collect information while debugging.