Let's stop parser Hell
David Piepgrass
qwertie256 at gmail.com
Sat Jul 7 14:52:08 PDT 2012
> What I like about it is not its performance, but how it matches
> the way we think about languages. Humans tend to see overall
> structure first, and examine the fine details later. The tree
> parsing approach is similarly nonlinear and can be modularized
> in a way that might be more intuitive than traditional EBNF.
That reminds me, I forgot to write a another advantage I expected
the three-phase approach to have, namely, that it seems easier to
tell what the programmer "meant" with three phases, in the face
of errors. I mean, phase 2 can tell when braces and parenthesis
are not matched up properly and then it can make reasonable
guesses about where those missing braces/parenthesis were meant
to be, based on things like indentation. That would be especially
helpful when the parser is used in an IDE, since if the IDE
guesses the intention correctly, it can still understand broken
code and provide code completion for it. And since phase 2 is a
standard tool, anybody's parser can use it.
Example:
void f() {
if (cond)
x = y + 1;
y = z + 1;
}
} // The error appears to be here, but it's really 4 lines up.
More information about the Digitalmars-d
mailing list