Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative parser: test Lark #87

Open
decalage2 opened this issue Nov 29, 2019 · 0 comments
Open

Alternative parser: test Lark #87

decalage2 opened this issue Nov 29, 2019 · 0 comments

Comments

@decalage2
Copy link
Owner

decalage2 commented Nov 29, 2019

In practice, the current VBA parser implemented with pyparsing is very slow. In the past I made some tests with ANTLR4 (issue #19), but its python runtime is even slower than pyparsing.
Other issues with pyparsing:

  • the grammar of the parser and the VBA emulation layer are mixed together because we're using the same classes for both. While it is convenient for a small grammar, with a complex parser such as ViperMonkey it makes maintenance difficult, and it is impossible to test different parsers without touching the emulation layer.
  • the current grammar tries to parse the whole VBA code in one go, so any exception breaks the whole parsing. I started to develop a line-based parser but it's too much work.
  • debugging the grammar is very difficult.

Lark is another parser for python that looks faster than pyparsing, and could allow us to separate the parser from the VBA emulation engine: https://github.com/lark-parser/lark

And there are other options: https://tomassetti.me/parsing-in-python/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant