Re: Design/structure X3 parser more like Qi parser

On 02-12-16 12:33, Sandro Pirkwieser wrote:
> The disadvantages of (1) are that one always has to pay the costs of
> initializing the static parser
Well. Seeing how many parts are constexpr (or can be in c++17) that cost
is likely imaginary.

If you don't care for parser performance and somehow mind a lot about
skipping static initializers (when is this a use-case?), you can always
use function-local scoped rules, using `x3::any_parser` to type-erase
any rule that needs to be reentrant. I think `x3::any_parser` is a close
cousing to `qi::rule` in that respect.

> When dealing with larger and complex parsers, these things matter.
> Having the parser encapsulated in a class would solve these issues, as
> was the case for Qi.

I fail to see why encapsulating parsers in a class changes much. I think
that's in the mind.

If you want you can trivially wrap entire (sub)grammars in a Qi-like
grammar struct: quick sketch
https://gist.github.com/sehe/7149067e6d5ef7edb36edb1867f110bc (note that
inspecting the assembly and `nm -C` output shows no static
initialization code has been generated)

As a third option, it could be good to note that the previous is pretty
close to a custom X3 parser. If you make the implementation inline and
change the interface slightly, you have a native X3 parser object
(sample:
https://stackoverflow.com/questions/37669936/spirit-qi-how-can-i-write-a-nonterminal-parser/37823837#37823837)

I feel the best results are to be had mixing and matching the above. I'd
probably concentrate on any_parser (for pimpl-ing the definitions) and
custom X3 parsers, because I like how they can keep you a bit away from
paying the MACRO/explicit instantiation tax.

> so far we used Spirit Qi for our parsers. Mainly due to large
> compilation times we were eager to experiment with X3.
If you don't mind my asking, what have been other limitiations you have
run into?

Personally I miss other things the most (like qi::lazy, qi::locals and
inherited attributes). Basically anything that could make a parser
stateful is harder in X3, and even with `x3::with<>` the semantics are
subtly different in unfortunate ways.

Oh, and sometimes phoenix was pretty nice for expressing semantic
actions, but that's largely syntactic sugar.

Cheers,

Seth


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot