Problem parsing with LALR

I’m not sure if it’s fault of grammar incompatible with LALR or is it a bug. Here it goes:

• Python 3.7.0
• lark revision 3c1c867b5f59397757dfec65d98d96e15b7de6e2
• grammar.lark (extremely boiled down dhall grammar)

  whitespace_chunk: " " | "\n"
  whitespace_optional: whitespace_chunk*
  
  reserved_func: "f" whitespace_optional
  open_parens: "(" whitespace_optional
  close_parens: ")" whitespace_optional
  
  expression_application: expression_parens (whitespace_chunk expression_parens)*
  expression_parens: expression_reserved | (open_parens expression_application 
  close_parens)
  expression_reserved: reserved_func
  
  start: whitespace_optional expression_application
  

• input f (f f)
• earley can parse (lark.Lark(open('grammar.lark'), parser='earley').parse('f (f f)'))
• lalr fails to parse (lark.Lark(open('grammar.lark'), parser='lalr').parse('f (f f)')) - raises lark.exceptions.UnexpectedToken
• standalone lalr also fails to parse

If this is because of this grammar being not parsable by LALR, I wonder if it would be possible to add error messages telling this. Currently I get something like “Unexpected token ‘(’, expected one of …”. For me, ideally constructing parser from grammar of unsupported class should raise “Can’t do it. Fix your grammar to be lalr.”.

[erezsh]

You can use Earley. It’s as capable as GLR, though perhaps not as fast.

After long battle against LALR parsing tables

As I said, they aren’t a good way to understand the algorithm.

[SupraSummus]

After long battle against LALR parsing tables I think I’ve lost. The language I’m trying to encode may not be LALR or maybe I’m just not understanding LALR enough. Currently I’m switching to GLR parser and it seems a lot easier (and slower probably, but still faster than earley).

@erezsh thank you very much for support and explaining things 😉