On Tue, 11 Oct 2022 at 06:34, Peter J. Holzer <hjp-pyt...@hjp.at> wrote: > > On 2022-10-10 09:23:27 +1100, Chris Angelico wrote: > > On Mon, 10 Oct 2022 at 06:50, Antoon Pardon <antoon.par...@vub.be> wrote: > > > I just want a parser that doesn't give up on encoutering the first syntax > > > error. Maybe do some semantic checking like checking the number of > > > parameters. > > > > That doesn't make sense though. > > I think you disagree with most compiler authors here. > > > It's one thing to keep going after finding a non-syntactic error, but > > an error of syntax *by definition* makes parsing the rest of the file > > dubious. > > Dubious but still useful.
There's a huge difference between non-fatal errors and syntactic errors. The OP wants the parser to magically skip over a fundamental syntactic error and still parse everything else correctly. That's never going to work perfectly, and the OP is surprised at this. > > What would it even *mean* to not give up? > > Read the blog post on Lezer for some ideas: > https://marijnhaverbeke.nl/blog/lezer.html > > This is in the context of an editor. Incidentally, that's actually where I would expect to see that kind of feature show up the most - syntax highlighters will often be designed to "carry on, somehow" after a syntax error, even though it often won't make any sense (just look at what happens to your code highlighting when you omit a quote character). It still won't always be any use, but you do see *some* attempt at it. But if the OP would be satisfied with that, I rather doubt that this thread would even have happened. Unless, of course, the OP still lives in the dark ages when no text editor available had any suitable features for code highlighting. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
