Trying to parse leads to crash.

Describe the bug

Trying to parse this string (using LALR(1))

EQUATIONS 1
$foo = +5+-3/condensorInput

using this grammer

?start: ddck

ddck: block+

?block: equations | unit

unit: header parameters inputs

header: "UNIT" unit_number "TYPE" type_number

unit_number: POSITIVE_INT

type_number: POSITIVE_INT

parameters: "PARAMETERS" number_of_parameters parameter+

number_of_parameters: POSITIVE_INT

parameter: variable_name | literal

inputs: "INPUTS" number_of_inputs input+

number_of_inputs: POSITIVE_INT

input: variable_name | literal

equations: "EQUATIONS" number_of_equations equation+

number_of_equations: POSITIVE_INT

equation: assignment_target "=" expression

assignment_target: explicit_var_name

?expression: unary_expression | binary_expression | func_call

?unary_expression: literal
    | variable_name
    | negation
    | "(" expression ")"
    | output

?negation.1: "-" expression

literal: SIGNED_NUMBER

output: "[" unit_number "," output_number "]"

output_number: INT

binary_expression: expression binary_op expression

func_call: func_name "(" (expression ("," expression)* )? ")"

func_name: FUNC_NAME

?binary_op: plus | minus | times | divided_by

plus: _PLUS

minus: _MINUS

times.2: _TIMES

divided_by.2: _DIVIDED_BY

variable_name: explicit_var_name | computed_var_name

explicit_var_name: shared_var_name | private_var_name

shared_var_name: SHARED_VAR_NAME

private_var_name.1: PRIVATE_VAR_NAME

computed_var_name: COMPUTED_VAR_NAME

SHARED_VAR_NAME: "$" NAME

PRIVATE_VAR_NAME: NAME

COMPUTED_VAR_NAME: "@" PORT_NAME "." COMPUTED_VAR_NAME_TYPE

PORT_NAME: NAME

COMPUTED_VAR_NAME_TYPE: "temp" | "mfr"

FUNC_NAME: NAME

NAME: LETTER (LETTER|DIGIT|"_")*

_PLUS: "+"

_MINUS: "-"

_TIMES: "*"

_DIVIDED_BY: "/"

POSITIVE_INT: POSITIVE_DIGIT DIGIT*

POSITIVE_DIGIT: "1".."9"

SIGNED_NUMBER: ("+"?|"-") NUMBER

COMMENT: /(\*\*|!)[^\n]*/

%import common.INT

%import common.NUMBER

%import common.LETTER

%import common.DIGIT

%import common.WS

%ignore COMMENT

%ignore WS

at https://www.lark-parser.org/ide/ gives me the following error:

PythonError: Traceback (most recent call last):
  File "/lib/python3.9/site-packages/lark/parsers/lalr_parser.py", line 126, in feed_token
    action, arg = states[state][token.type]
KeyError: '$END'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/lib/python3.9/asyncio/futures.py", line 201, in result
    raise self._exception
  File "/lib/python3.9/asyncio/tasks.py", line 256, in __step
    result = coro.send(None)
  File "/lib/python3.9/site-packages/_pyodide/_base.py", line 494, in eval_code_async
    await CodeRunner(
  File "/lib/python3.9/site-packages/_pyodide/_base.py", line 345, in run_async
    coroutine = eval(self.code, globals, locals)
  File "<exec>", line 1, in <module>
  File "/lib/python3.9/site-packages/lark/lark.py", line 581, in parse
    return self.parser.parse(text, start=start, on_error=on_error)
  File "/lib/python3.9/site-packages/lark/parser_frontends.py", line 106, in parse
    return self.parser.parse(stream, chosen_start, **kw)
  File "/lib/python3.9/site-packages/lark/parsers/lalr_parser.py", line 41, in parse
    return self.parser.parse(lexer, start)
  File "/lib/python3.9/site-packages/lark/parsers/lalr_parser.py", line 171, in parse
    return self.parse_from_state(parser_state)
  File "/lib/python3.9/site-packages/lark/parsers/lalr_parser.py", line 188, in parse_from_state
    raise e
  File "/lib/python3.9/site-packages/lark/parsers/lalr_parser.py", line 182, in parse_from_state
    return state.feed_token(end_token, True)
  File "/lib/python3.9/site-packages/lark/parsers/lalr_parser.py", line 129, in feed_token
    raise UnexpectedToken(token, expected, state=self, interactive_parser=None)
lark.exceptions.UnexpectedToken: Unexpected token Token('$END', '') at line 2, column 14.
Expected one of: 
	* LPAR

To Reproduce

See above.

What I expect it to do

I don’t know why it can’t parse it. Using Earley it works. However, I don’t get it to respect operator precedence, then (* over +, e.g.). Why doesn’t this string parse using LALR(1) and how would I go about enforcing operator precedence using Early.

Thanks a lot, Damian

[erezsh]

It’s not so simple, because some ambiguity is expected in LALR(1) grammars, and if we disallow it, it will make writing grammars a lot more cumbersome. And it’s not simple to know if it’s “good” or “bad” ambiguity, because that requires an understanding of the target language that only the author can have.

[erezsh]

It might be possible to add a “strict” mode, and maybe add a few more language constructs to prevent ambiguity. But that would require some research, I’m not aware of an existing solution.