-
Notifications
You must be signed in to change notification settings - Fork 1
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
Parser #3
Comments
I think it would keep our work focused on the core functionality if we leave aside parser concerns to begin with. Rust syntax is expressive enough to represent maps (associative) and vectors (sequential) fairly well, which lets us represent any structure of data that is appropriate input to a MF API. I define AST (Abstract Syntax Tree) as the tree that pops out when you parse a file according to its syntax. It's often used in the context of parsing executable code, but not strictly limited to such. It's not exactly what we need -- perhaps it's a bit lower level. We can start off by just describing the input data for a message formatter -- maybe you start off with a target locale, a message template (interleaved strings and placeholders), and some specific values to plug into the template? Something like that might be enough to drive the code, in a "data-driven" way, where the other part of the work is producing the impl functions to make the output behave as we expect. And later on, we can build serialization upon that as needed. |
I see. Yeah, that makes sense! |
I'll close it for now then, and we can later reopen if needed. |
Do we want to write a parser to accompany the AST?
We could either write something by hand (I have a lot of experience writing parsers in Rust, and I believe for the initial subset we could have a sub-100 lines of code parser), or we can use a generator like
nom
.The text was updated successfully, but these errors were encountered: