Open fabioz opened 1 year ago
I agree, a custom lookahead, aka LALR(k), would be a really nice feature. And a very difficult one to implement correctly.
Why are you explicitly putting down WS
? Since that is ignored anyway, it has no purpose here.
Why are you explicitly putting down
WS
? Since that is ignored anyway, it has no purpose here.
Humm... probably I don't understand it enough then. Why is it ignored? Is there a way to not ignore it? In this particular grammar I'd like to have 2 spaces as a separator. Is this not possible?
i.e.: The code below would be valid code (as the identifier can have spaces):
Function name Function arg 1, Function arg 2
oh lol, I thought you had an %ingnore
statement in there since you were using the PythonIndenter. That one might break if you aren't ignoreing Inline WS:
By default the LALR grammar can have only a single lookahead, but it'd be really nice if it could have a custom lookahead on specific cases (I got used to JavaCC which implements this with something as a
LOOKAHEAD(2)
in the proper place to avoid the restriction).The use case I have is below. From what I see, apparently the
?identifier: NAME (WS NAME|WS NAME_CONT)*
sees theWS
and takes that route but can't see that the whole construct is actually optional and should not keep matching (in JavaCC I'd put a LOOKAHEAD(2) there and it'd try to make the whole match and if it matched just the first rule but not the 2nd it'd be Ok).p.s.: although earley works for this particular construct it doesn't work for the full grammar I'm working at, so, using it isn't really a solution...
Error
Sample code