The conflict comes from the grammar being ambiguous. If you have a PARAM_LIST that is

WORD = NUM NUM 

is that one PARAM (a WORD = VALUES with 2 NUMs) or two (a WORD = VALUES with one NUM followed by a bare NUM param?

The default "prefer shift" resolution will treat it as the former -- basically any VALUES will absorb as many NUM tokens as it can, leaving none to be stand-alone params. If that is the preferred resolution, then you can just leave it as that, but if you really want to shuw up the "warning" message, you can either:

1. Add precedence rules to shut it up: a %right NUM is all you actually need (prefer shifting a NUM token to reducing a rule with a NUM token like VALUES: VALUES NUM.) The only real danger here is that if you later add more rules using NUM this precedence might trigger when you don't expect it (hiding a conflict that you would prefer to resolve a different way).

2. Refactor the grammar to make the ambiguity go away. Something like

    NUM_PARAMS: NUM | NUM_PARAMS NUM ; WORD_PARAM: WORD EQUALS VALUES ; WORD_PARAMS: WORD_PARAM | WORD_PARAMS WORD_PARAM ; PARAM_LIST: NUM_PARAMS WORD_PARAMS | NUM_PARAMS | WORD_PARAMS ; 

This makes it clear that when you have both params that are bare NUMs and params that are WORD = VALUES all the bare NUMs must come first.

The conflict comes from the grammar being ambiguous. If you have a PARAM_LIST that is

WORD = NUM NUM 

is that one PARAM (a WORD = VALUES with 2 NUMs) or two (a WORD = VALUES with one NUM followed by a bare NUM param?

The default "prefer shift" resolution will treat it as the former -- basically any VALUES will absorb as many NUM tokens as it can, leaving none to be stand-alone params. If that is the preferred resolution, then you can just leave it as that, but if you really want to shut up the "warning" message, you can either:

1. Add precedence rules to shut it up: You want shifting a NUM to have higher precedence that the rule PARAM: WORD EQUAL VALUES. The latter will get the precedence of the EQUAL token, so that needs to have higher precedence than NUM. The main danger in using the precedence rules is in overspecifying them and having them trigger when you don't expect. This might hide a conflict if you have any other rules that use the tokens NUM or EQUAL

2. Refactor the grammar to make the ambiguity go away. Something like

    NUM_PARAMS: NUM | NUM_PARAMS NUM ; WORD_PARAM: WORD EQUAL VALUES ; WORD_PARAMS: WORD_PARAM | WORD_PARAMS WORD_PARAM ; PARAM_LIST: NUM_PARAMS WORD_PARAMS | NUM_PARAMS | WORD_PARAMS ; 

This makes it clear that when you have both params that are bare NUMs and params that are WORD = VALUES all the bare NUMs must come first.

If, on the other hand, you would rather have the ambiguity resolved the other way (so that the trailing NUM is a separate param), the easiest fix is probably just to change the WORD EQUAL VALUES to WORD EQUALS NUM.

The conflict comes from the grammar being ambiguous. If you have a PARAM_LIST that is

WORD = NUM NUM 

is that one PARAM (a WORD = VALUES with 2 NUMs) or two (a WORD = VALUES with one NUM followed by a bare NUM param?

The default "prefer shift" resolution will treat it as the former -- basically any VALUES will absorb as many NUM tokens as it can, leaving none to be stand-alone params. If that is the preferred resolution, then you can just leave it as that, but if you really want to shuw up the "warning" message, you can either:

1. Add precedence rules to shut it up: a %right NUM is all you actually need (prefer shifting a NUM token to reducing a rule with a NUM token like VALUES: VALUES NUM. The only real danger here is that if you later add more rules using NUM this precedence might trigger when you don't expect it (hiding a conflict that you would prefer to resolve a different way).

2. Refactor the grammar to make the ambiguity go away. Something like

   NUM_PARAMS: NUM | NUM_PARAMS NUM ; WORD_PARAM: WORD EQUALS VALUES ; WORD_PARAMS: WORD_PARAM | WORD_PARAMS WORD_PARAM ; PARAM_LIST: NUM_PARAMS WORD_PARAMS | NUM_PARAMS | WORD_PARAMS ;

This makes it clear that when you have both params that are bare NUMs and params that are WORD = VALUES all the bare NUMs must come first.

The conflict comes from the grammar being ambiguous. If you have a PARAM_LIST that is

WORD = NUM NUM 

is that one PARAM (a WORD = VALUES with 2 NUMs) or two (a WORD = VALUES with one NUM followed by a bare NUM param?

The default "prefer shift" resolution will treat it as the former -- basically any VALUES will absorb as many NUM tokens as it can, leaving none to be stand-alone params. If that is the preferred resolution, then you can just leave it as that, but if you really want to shuw up the "warning" message, you can either:

1. Add precedence rules to shut it up: a %right NUM is all you actually need (prefer shifting a NUM token to reducing a rule with a NUM token like VALUES: VALUES NUM.) The only real danger here is that if you later add more rules using NUM this precedence might trigger when you don't expect it (hiding a conflict that you would prefer to resolve a different way).

2. Refactor the grammar to make the ambiguity go away. Something like

    NUM_PARAMS: NUM | NUM_PARAMS NUM ; WORD_PARAM: WORD EQUALS VALUES ; WORD_PARAMS: WORD_PARAM | WORD_PARAMS WORD_PARAM ; PARAM_LIST: NUM_PARAMS WORD_PARAMS | NUM_PARAMS | WORD_PARAMS ; 

This makes it clear that when you have both params that are bare NUMs and params that are WORD = VALUES all the bare NUMs must come first.