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