in reply to Cannot get Marpa::R2 to prioritise one rule over another

I don't have a fix for your actual problem, but The reason it refuses to select the ipv4 is because of longest-token matching. NAME matches a longer token than NUMBER, therefore it always wins.

Update: Change NAME to not accept a dot (and update hostname rule) and then it will work as you originally had:

my $rules = <<'END_OF_GRAMMAR'; lexeme default = latm => 1 :default ::= action => [name,values] :start ::= <entry> <entry> ::= <op> (SP) <hostaddr4> <op> ::= 'add' | 'remove' <ipv4> ::= NUMBER ('.') NUMBER ('.') NUMBER ('.') NUMBER <hostname> ::= NAME+ separator => DOT <hostaddr4> ::= <ipv4> | <hostname> DOT ~ '.' SP ~ [\s]+ NAME ~ [^\s.]+ NUMBER ~ [\d]+ END_OF_GRAMMAR

Good Day,
    Dean

Replies are listed 'Best First'.
Re^2: Cannot get Marpa::R2 to prioritise one rule over another
by Anonymous Monk on Jan 21, 2021 at 20:46 UTC

    Thanks. I won't say the reasoning makes absolute sense to me yet, but I do confirm that your approach does allow differentiation between IPv4 and not-IPv4 at parse-time -- albeit one that I have to recompose back to a single string.

    Given that I'm also going to have to handle IPv6 at some point, and the complexities involved in that, I'm probably going to flatten the <hostaddr4> rule to simply <hostaddr> ::= NAME and lay off to a custom action to determine IPv4, IPv6 or hostname in my larger grammar. It would have been nice to formalise support for the three types in the grammar definition, but I'm not going to lose sleep over it.

    That said, if you (or anyone) can shed light on why the order of rules, or use of || vs | makes no difference, I would be keen to understand. Props to the package author for taking the time to document thoroughly, but it's not an easy read for someone for whom this isn't going to be a full-time gig!