add support for silent rule matching

[radhermit]

Similar to the functionality provided by pest's silent rules. In essence, silent expressions would still operate in the same fashion, but their match content would be skipped for bound actions, slices, or similar that contain them. I assume something like silent! { e } would probably work syntax-wise.

[kevinmehall]

There is already quiet!{} which suppresses its contents from appearing in error messages. Unlike pest, rust-peg doesn't build any kind of syntax tree on its own, so to ignore tokens, simply leave them out of whatever return value you build in the action. Slice expressions ($()) use the parser only to find the start and end positions and return a borrowed slice of the input string, so it's not possible for them to skip parts of the input within that range, because it wouldn't be contiguous.

Or if I'm misunderstanding what you mean by this, a code example would be helpful.

[radhermit]

Or if I'm misunderstanding what you mean by this, a code example would be helpful.

In essence, I'm trying to simplify what I see are "stub" rules in my grammar that parses Gentoo package dependencies. For example see the version rule that splits the revision parsing into a separate rev_str() rule due to not wanting to also capture the -r part of the matched string.

Is there some way to match a larger string while capturing a section of it without using separate rules? From playing around with things, I think variable scoping prevents nested action expressions or other similar hacks that could make this work, but perhaps I'm doing things wrong.

[kevinmehall]

Action blocks don't have to be at the end of a rule -- a sequence with labels followed by a block is a first-class expression that can be used to match multiple things and control the return value of the subexpression. In general, anything you can put after the = of a rule you can wrap in parentheses and include inline in another rule.

e.g. you could inline rev_str like:

pub rule version() -> (&'input str, Option<&'input str>)
    = ver:$(
        quiet!{
            ['0'..='9']+ ("." ['0'..='9']+)*
            ['a'..='z']?
            ("_" ("alpha" / "beta" / "pre" / "rc" / "p") ['0'..='9']*)*
        } / expected!("version")
    ) rev:(quiet!{"-r"} r:revision() { r })? { (ver, rev) }

Of course there's a point where it gets unreadable to include too much in a single rule and it makes sense to split it up.

[radhermit]

Ah thanks, that makes sense.

[kevinmehall]

This example is a fairly common case with the subexpression inside * or ?. I've considered adding a syntactic sugar for returning one of the items out of a sequence without having to introduce another variable name. Perhaps something like

("-r" >:revision())?

But I'm wary of adding more ad-hoc syntax that users would have to learn.

[radhermit]

Yes, this could be useful since I'm not overly keen on embedded action blocks due to the general complexity increase for reading rules using them, but I'll let you can decide if increasing optional syntactical complexity is worth it for this feature. 😄

[Mingun]

You can get inspiration from peggy's @-operator