This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author davidhalter
Recipients BTaskaya, Peter Ludemann, carljm, corona10, davidhalter, eric.snow, gregory.p.smith, gvanrossum, hroncok, xtreak
Date 2020-07-30.11:11:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1596107507.79.0.994572405674.issue40360@roundup.psfhosted.org>
In-reply-to
Content
@gvanrossum

> Does parso have to be pure Python? If not, we could generate C code like we do for CPython's parser. 

I would rather write the parser either in C or Rust. So no, parso does not need to be pure Python.

> Now, that doesn't work for incremental parsing, but I did an alternative implementation that uses a stack machine, also in C, that's only 2x slower than the PEG parser. Maybe that could be adapted to incremental parsing (because it's a stack machine). Error recovery is still a research project (at least for me -- I'm actually reading papers :-).

Makes sense! I was also thinking about GLL parsing. Obviously GLL does not cover all cases where PEG could potentially work, but I doubt that Python ever moves to a place where GLL would not be sufficient.

I'm also doing a bit of research on Rust parsers and trying to find a solution for my parsing needs in the future. (I'd rather have a Rust parser than a C one, because I like the language better and both should still work in Python).

Please let me know if you're making a lot of progress with PEG parsers and error recovery/incremental parsing. I'm definitely interested in copying an approach if it works :).
History
Date User Action Args
2020-07-30 11:11:47davidhaltersetrecipients: + davidhalter, gvanrossum, gregory.p.smith, carljm, eric.snow, hroncok, corona10, xtreak, BTaskaya, Peter Ludemann
2020-07-30 11:11:47davidhaltersetmessageid: <1596107507.79.0.994572405674.issue40360@roundup.psfhosted.org>
2020-07-30 11:11:47davidhalterlinkissue40360 messages
2020-07-30 11:11:46davidhaltercreate