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. > 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. But the same problem applies to compilers. It's not very important if a compile run only takes a second or so but even then it might be helpful to see several error messages and not only one at a time. It becomes much more important as compile times get longer (as an extreme[1] example, when I worked on a largeish cobol program in the 1980s, compiling the thing took about half an hour. I really wanted to fix *everything* before starting the compiler again.) Marijn isn't the only person who revisited this problem recently[2]. I've read a few other blog posts and papers on that topic at about the same time. hp [1] Yes, there are programs where a full compile takes much longer than that. But you can usually get away with recompiling only a small part, so you don't have to wait that long during normal development. That cobol compiler couldn't do that. [2] "Recently" means "in the last 10 years or so". -- _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | h...@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
-- https://mail.python.org/mailman/listinfo/python-list
