Conceptually about right. Daffodil has 3 trees in the compiler
First is the DSOM tree. This is the AST. Its structure matches that of the schema document (s). Second is the "Gram" or grammar tree. (So called because we tried to make them work sort of like Scala's combinator parser "rules" for a grammar, and kind of like guarded clause logic .... dubious whether we succeeded.) Gram nodes hang off of the DSOM nodes. These are the "code generators". They have two primary methods: parser, which returns a parser unparser which returns an unparser The parser and unparser themselves are the third tree of stuff. They are the actual runtime data structures. So you would create similar cppParser and cppUnparser methods on the Gram objects that return instead of Scala objects that are instances of Parser/Unparser, would be objects containing strings of C++ code that achieve the same end when compiled and run. These objects would have gen() methods which emit the C++ code recursively to a file(s). We can discuss further at ApacheCon today or tomorrow AM. ________________________________ From: Julian Feinauer <j.feina...@pragmaticminds.de> Sent: Wednesday, September 11, 2019 1:30 PM To: dev@daffodil.apache.org <dev@daffodil.apache.org> Subject: [GENERATION] Code generation with Daffodil Hi guys, I just had a discussion yesterday with Mike and Steve and we already had several discussions before in the PLC4X project. We like Daffodil but have the issue that we do not fit with the “Interpreter” Runtime it currently is. Mainly for two issues, performance and interoperability. So Ideally, I would like to have a piece of code which takes a DFDL Schema file and generated Code which is specifically to parse the given schema, probably in a given output. Ideally in multiple languages. As its not (yet) Christmas, I guess I will not get that for free so I played around a bit with the code and tried to understand it as good as possible and for me it seems that it is not that undoable as I initially thought (I already checked some months ago). In fact, if I get it right, the key would be to add another method `translate: AstNode` to the `Parser` trait. This should then generate an Ast (Sub-)node which represents all the action that would be done in the regular `parse` method. Then, we could finally, try to translate this Ast to Code and dump it to a file (I guess this is the rather easy part). This is just a rough thought, but I wanted to get it to the list and probably we will find some time to discuss it at ACNA. Julian
