Example synax below consisting of 3 groups of elements with the 2nd either/or repeating:
name
optionally followed by properties (b=1) or arguments (just b). In general the key/arg names can be different, so I've made an equivalent regex b manually to force a branch point, and then I either match = or no = with a negative lookahead
ending with a ; or a newline terminator
Then I've noticed that the positive lookahead pops 2 contexts, which prevents the chain from continuing, so either manually changing that to 1 or adding an empty '' match fixes it
But then this is totally unintuitive, I don't get why I need an empty match "dirtying" this clean conceptual rule.
Is there a way to make a 1 pop by the lookahead itself?
main : (~test )* ;
test : 'name' (pprop | aarg)* ';|\n' ;
pprop{variable.property } : ('b'{↓ re equiv to ⸙} '=' '1');
# aarg{ entity.other.attribute-name} : ('b'{↑ re equiv to ⸙} '(?!=)' ); # FAILS
aarg{ entity.other.attribute-name} : ('b'{↑ re equiv to ⸙} '' '(?!=)' ); # Works
Testing text, the fail appears by the rule stoping at the first b argument, refusing to go forward to match subsequent args/props
name b=1 b=1 b b b=1 b b=1 b b ;
name b=1 b=1 b b b=1 b b=1 b b b=1;
name b b b=1 b b b b=1;
Example synax below consisting of 3 groups of elements with the 2nd either/or repeating:
name
b=1
) or arguments (justb
). In general the key/arg names can be different, so I've made an equivalent regexb
manually to force a branch point, and then I either match=
or no = with a negative lookahead;
or a newline terminatorThen I've noticed that the positive lookahead pops 2 contexts, which prevents the chain from continuing, so either manually changing that to
1
or adding an empty''
match fixes it But then this is totally unintuitive, I don't get why I need an empty match "dirtying" this clean conceptual rule.Is there a way to make a
1
pop by the lookahead itself?Testing text, the fail appears by the rule stoping at the first
b
argument, refusing to go forward to match subsequent args/props