(re-)Implement GMX RTP parser using lark-parser #359
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR (re) implements the RTP parser using the lark-parser parsing framework, where the file grammar is separated from the interpretation.
If we like this style we'll use this to parse FF files as well, after we redo that file format.
This PR is a draft because it's main purpose is to foster some discussion. It also requires more extensive testing. On top of that there is one TODO left regarding the generation of 1-4 pairs between hydrogens, and docstrings are missing.
@fgrunewald what's your opinion/take on this?
The main advantages/disadvantages that I see are the following:
+ The grammar and syntax are explicitly defined, which helps documentation
+ It's faster than the SectionLineParser (but I haven't quantified this)
+ When we implement the FF format as well we can start inheriting/including grammar from the other files, which makes the syntax more uniform
+ It'll allow us to write more complex things for e.g. the JSON parts of the FF format, relaxing the need for quotes and such. See #175
- We need to redo the parsers. Again.
- The interpreter logic is not always as clearly depicted as with the sectionlineparser, but that may also be because I'm not good at working with abstract syntax trees.