|Syntax directed parsing firstname.lastname@example.org (Don Walters) (1999-08-27)|
|Re: Syntax directed parsing email@example.com (Alexei Boukirev) (1999-08-27)|
|From:||"Alexei Boukirev" <firstname.lastname@example.org>|
|Date:||27 Aug 1999 12:33:03 -0400|
I've been thinking on this problem for a while already. I like the
way modern IDEs work when they suggest a list of methods for an object
or information about parameters. My understanding is that having
parser integrated with editor is a big plus for parser. You need to
parse the entire file once upon loading it into editor and build an
AST (since the text may be syntactically incorrect you still need a
recovery support in your parser). Then you'll have nodes in AST point
to locations in editor buffer. Once user starts entering/modifying
text, you have to find the AST node starting just before the insertion
point, invalidate subtree starting with this node, and next time only
parse the part of buffer between this node's start point and next
valid node start point (buffer location). You start parsing again
once user pressed arrow keys or any other key to change cursor
position without editing.
Now, I may be wrong in details, but that's the general idea.
Another part of it is parser error recovery. Depending on language
being parsed, you'll come up with a list of "recovery tokens." For
example, ';', ')', '}', '"', etc. Each one of them denotes a definite
end of some language construct. In the rule for that construct you
need to catch a parser/lexer exception and force lexer (not parser) to
skip to that closing token, then return from the rule. It is
extremely difficult to recover from the series of 'if' statements, but
you can successfully recover 'block' statement most of the time
I don't know how this would work with ANTLR's automatic AST building. It
probably won't - you'll have to build AST explicitly.
Another idea, which comes from my work on a syntax-oriented editor some
years ago is to give user a tool (key combinations) to enter flow control
statements at once (always open AND close braces or always 'begin'-'end'
pair), and allow to enter anything only in declarations part and in
expressions. Then you'll have less to parse. If user enters 'if' in
expression, you just report an error - your parser knows that there should
be no 'if's in expression.
BTW, we ended up having integrated debugger work on partial syntax tree.
Then the project just died because nobody wanted to sponsor it.
Hope that helps,
Don Walters <email@example.com> wrote in message
> I am considering developing a syntax-directed editor for a language.
> The behavior I'd like is to give the user feedback on syntax errors by
> underlining the first error token, etc... Much like the Visual J++
> editor if you have seen that (so it is non-intrusive but helpful).
Return to the
Search the comp.compilers archives again.