making rules run-time conditional, and a related parse tree help request

[brouhaha]

For one of my projects using PEGTL 4, I want a state object I pass to the parser to contain booleans that enable or disable certain rules. There might already be some method by which this can be done, which I have overlooked. I've done it by writing a custom rule called peg_cond. The template parameters of peg_cond include the member variable pointer (into the first state object), a rule to be invoked if that member variable is true, and rule to be invoked if the member variable is false. The latter defaults to failure.

The seems to work fine in my project, giving the expected parsing results. However, it interferes with the parse tree selector of the conditional rule. No node is generated for the rule, even if it has a true selector, though nodes are generated as appropriate for its child nodes.

I've put peg_cond.hh, along with a crude demo/test program, in a Codeberg repository:

https://codeberg.org/brouhaha/peg_cond_test

As written, my code requires C++26, and compiles and runs with either GCC g++ 16.2.1 or clang++22.1.8.

My rules have rule_t and subs_t declarations, but perhaps I'm missing something else that interferes wtih the selector of the direct child rule. Any help would be appreciated, as would any other constructive criticism

Should peg_cond be deemed useful and suitable as a contribution to PEGTL, you are welcome to it.

[ColinH]

Interesting, this quite a unique and new requirement. Can you explain briefly the rationale and the use case, just very high level?

The interference with the parse tree might just be due to directly calling RuleIf::match and RuleElse::match instead of going through the control. That means you are disabling all control functions and also all actions for RuleIf and RuleElse.

/* const bool result = */ Control< Rule >::template match< A, M, Action, Control >( in, st... );

Is the correct way to call a sub-rule in your case, let me know if that is not enough to fix the parse tree issues.

[brouhaha]

The use case is having a single grammar that covers multiple variants of a language, such as Ada-83 and Ada-95. I'll try using the method you provided. Thank you!

[brouhaha]

That solved the problem! Thanks again!

[ColinH]

Btw, about the rule peg_cond_failure, why could tao::pegtl::failure not be used as default "else" rule?

[brouhaha]

That was what I initially tried, but g++ complained that template arguments didn't match.

[ColinH]

Right, of course. It should work now, with the correct way of invoking the sub-rules.

(Your direct call did not take into account that some rules use the simplified call interface with fewer template parameters and no states.)

[brouhaha]

It does! Thanks!

[ColinH]

As for inclusion in the PEGTL, let me think about it some more. The PEGTL is now switching to C++20, but I can imagine a solution that works there based on extracting the type of the state from the member object/function pointer and then using the typed get() as in match_typed_state. Not sure yet whether it is cleaner to implement this functionality as rule or as action (it wouldn't be the first one for which we have both).

[brouhaha]

I'm not trying hard to push this for inclusion. If you decide that it's worthwhile to include the general capability, I can easily imagine that you may have a better architecture for it.

I think that pack indexing is the only C++26 feature I'm using in my approach, and that could be replaced with template recursion in order to make it work with C++20.

I didn't include it in the code I shared, but I have a second version, only trivially different, that adds another template non-type-parameter to specifiy the index to the object to inspect, rather than always using zero.

I also left out some additional complication that deals with the possibility of the state object being a pointer or e.g. std::shared_ptr, and using a dererference before selecting the bool member. In my application, the state object is a std::shared_ptr.

[ColinH]

The rule peg_cond does several things all-in-one. It could be simplified to an atomic rule that tests/inspects the state(s) and succeeds or fails based on the result. That rule would then be used with if_then_else to recreate peg_cond. In that form it might be generic enough to add to the PEGTL. The hardest part is finding a good name :-)

[d-frey]

Simply test might be a good name?

[d-frey]

And following up my discussion with @ColinH : A rule that filters states (one version filtering by index, one by type?) could be placed between if_then_else and test, nicely selecting/filtering the state(s) that are tested, while the then and else-rules still see the full states. At least in my mind it's really coming together now 😅

[brouhaha]

"test" seems a bit generic. Maybe state_cond or state_test?

In the interest of conciseness, and since I don't see much use for it other than in an if/then or if/then/else situation, I like it merged, but I won't object if you separate it. if it's kept together, maybe something like state_if_then?

The help with howto invoke subrules properly with Control has helped me with another strange thing that I've been doing, which I may write up in another forum post later.

[ColinH]

Note that tao::pegtl::if_then_else can already use tao::pegtl::function as first sub-rule which leaves just a small gap to a more integrated/compact solution.