|RE: Syntax directed parsing firstname.lastname@example.org (1999-08-28)|
|Date:||28 Aug 1999 02:10:55 -0400|
|Organization:||Deja.com - Share what you know. Learn what you don't.|
Check out "Practical Algorithms for Incremental Software Development
Environments" by Tim Wagner available from his home page
ANTLR and PCCTS use a much different tree mechanism than he uses but I
think you could take some of his approach and make it work. The nice
thing about ANTLR is that it is recursive-descent, so it is much
easier to reason about exactly how the parsing takes place because the
source code is meant to be read by a human, as opposed to yacc's table
I'm not convinced that you would need to go to his level of detail as
far as re-parsing is concerned. For many applications you could parse
just the method or function someone is working on at interactive
speeds without the overhead of tracking all the dependencies, and have
nice clean boundaries for propagating the changes--replace the subtree
corresponding to that method.
ANTLR is quite capable of preserving whitespace during parsing and
tree transformations. I have a few problems with attaching comments
and whitespace "on the side" of a tree node, I think a different
approach is called for but that's another thread altogether,
especially if you aren't needing to reconstruct the parsed text with
all of the comments and whitespace intact.
You could also do a generalized parser that tracks nesting of
parenthesis and so on but doesn't deal with difficult issues such as
typedefs, include files, etc. I think you would find writing such a
beast in antlr easier to reason about than writing a bunch of regular
expressions and keeping track of state by hand.
If you're seriously considering ANTLR then email me and we can chat on
the phone--it's easier than the email ping-pong game.
> -----Original 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.