echeran
commented
4 years ago 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.
zbraniecki
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.