Erez Shinan

Yes, definitely brings it to the level of usability! It's still significant enough that it might be best to keep it optional, but at the 20% slowdown range, it's definitely...

Nice. If you can make it even faster, please do. Btw, what do you think are the odds that the original maintainer will merge your changes?

Hi @qntm, I also thank you for the quick reply, and for creating your library, which is proving very useful to us. There may be many other libraries, but most...

If it's 1500 LOC, a separate package is probably better. Also, that leaves room for expanding it in the future, perhaps returning some of the functions we removed from greenery...

@MegaIng I think it's best if you start in your own user. When it's mature for use (even alpha stage), we can move it to lark-parser. Name suggestions: 1) Interegular...

Well, for `!rule`, the optimization could be performed, and then reversed in post-processing by parsing the joined string. But that's probably not going to help performance. As for `%ignore`, that's...

@gward Hi Greg, I think the change you propose makes sense. @MegaIng Why do you think it's such a bad idea? Another alternative: You can subclass from Lexer and override...

There are currently two ways to perform the same task. The new one is, I believe, more idiomatic for Lark. It also uses an existing option (`transformer`) and doesn't require...

There is never a necessity to remove any feature, generally speaking, but it's a good idea to keep a library as lean and minimal as possible, both for the simplicity...

I think it's a nice idea, but I'm worried that it would clutter the grammar. Perhaps a cleaner approach, with a similar effect, would be to add the method `Tree.children_by_name(name)`,...