Erez Shinan

If I understand your question, then the answer is: Not really. Would it help if you could do something like this? ```python # pseudo-code, doesn't work yet from lark import...

I implemented it in the `inline` branch (see linked commit). Let me know if that works for you the way you expect.

@ThatXliner Because you don't always know at the grammar level. Sometimes it depends on the values (i.e. context-sensitive)

> it will get a Tree object passed to the defined functions That's weird. You can see in the `json_parser.py` example that it's not the case. Are you sure you...

I found greenery about a year ago, and was excited to use it for Lark. But it had two major problems: 1) As you said, it doesn't work with Python's...

@MegaIng Awesome, that is very encouraging! If the slowdown that's introduced isn't too noticeable, then perhaps, it's still worth doing as an optional feature. Even if it doesn't catch everything...

@MegaIng That sounds fantastic! I can't wait to give it a try (but I'll have to wait, life etc.) Keep me posted on your progress, please!

Nice, I'll look into it pretty soon! I think the biggest real grammar I have is `examples/python3.lark` But it's possible to create arbitrarily big grammars if necessary

@MegaIng Very cool! It definitely sounds like a good starting point. Well, you don't have to check all terminals, only the regexps. Constant strings are easy. Most grammars I've seen...

It sounds like optimizing `to_fsm` is the key for good performance.