-
-
Notifications
You must be signed in to change notification settings - Fork 252
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
Pluggable Backends #178
Comments
This is a very tricky issue. One of the points of pest is to not need an extra tool & step to generate your parser. My solution here would be to generate an optional However, if need does arise and pest is constantly used in other build environments, maybe it would make sense to crate a tool that can statically compile the parser and export the necessary glue to multiple PLs (C++ headers, Ruby gems?) |
A good first step here would probably be to have an attribute @dbrgn Willing to give this a try? |
I'm quite busy at the moment, so not in the next weeks. Maybe in summer, but don't wait for me on this issue :) |
If I am not mistaken, pest already has pluggable backends. You can see One can always write another crate which generates code for another language. However, at the moment, |
@Victor-Savu Yes. I agree that it makes sense to separate the optimizer in its own crate. I'll work on it once #159 is merged. |
On master, we've moved the optimizer into |
@jstnlef I agree. This was tagged 2.0 tentatively. |
I searched for a parser generator library that can parse my pest grammar file with few modifications and output C++{11,17} code. Unfortunately I did not find anything.
If pest had pluggable backends and could output parser source code in various languages, that would be really fantastic and would give it yet another advantage over other parsers.
Is anything like that planned / possible?
Probably depends on #158.
The text was updated successfully, but these errors were encountered: