Re: Design/structure X3 parser more like Qi parser
Sandro Pirkwieser <[email protected]>
| Newsgroups | gmane.comp.parsers.spirit.general |
|---|---|
| Message-ID | <4A73F31802B9FB46A4428BA93C0A3DEB050330B98AC8@hermes.ith-icoserve.com> |
Hi, @Mikael: thanks for your report and the "trick" with the init function. @Michael: yes, it would certainly work for some parsers, and I already used that style, but I think in this way the parser (grammar) is more trapped than encapsulated. @Seth: Thanks for all your info, I will reply to your points in the remainder. I'm still concerned about the basic structure of an X3 parser, but it remains open whether it is because of my current knowledge or the way X3 was designed and is intended to use. The main concern: with Qi one achieves a straightforward and clean encapsulation in a grammar (sub-)class, yet it is easy to use such a parser as a subparser in a larger one via including it as a class member. In X3 the encapsulation can only be "approximated", and it seems the more achieving this goal decreases the possibility of reusage and integration into another parser. It seems that our current design, along the guidelines of Qi, is somewhat contrary to that of X3. Regarding your recommendation, do you know of further info/doc about x3::any_parser and deriving from x3::parser_base? They are not covered by the official docs, as their usage is probably not intended(?). Until now we encountered no other limitations, but an unfortunate result instead. To get started I transformed a rather simple parser, which parses CSV input, from Qi to X3. The field separator is not fixed, hence it can be set with `x3::with<>`. As an upside the compile time is reduced to one third, which is quite impressive, but as a downside the runtime is up to twice as much. In order to rule out an overhead due to `x3::with<>` the separator was fixed, but it had no measurable effect. There were also two semantic actions in use, which basically added up single chars, which could be omitted by a bit of reformulating. But again, no effect on the runtime. This parser was thought of as a teaser for X3, but adding up the mentioned structural issues and the experiments leaves us with doubts whether we should pursue it further. Best regards, Sandro ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi