... > > > It would also require some work with the grammar actions, actions that > > would they have their "reverse" counterpart, that could be undone if they > > maintain a symbol table for example. The same for Init and after blocks.
> Probably we'd limit it to building syntax trees. I was wondering how you would proceed to maintain an IDE synthax highlighter and a symbol table, Sam Harwell has an external grammar, in this case would we need an external tree grammar that would parse the entire input at each modification (with a possible time lapse not to re-fire at each key-stroke)? Do you think of another way to do it (pointers?)? This is the only way I can think of it right now and it seems to me that it looses the interest of the incremental mechanism. Reverse actions could be called when branches are discarded/removed. Any comment on this? > > Incremental lexer/parser is also very good publicity, it is very much > > visible to the "outside" world, Xtext gains a lot of traction thanks to > > that single feature, it helps adoption. > Does it use the berkeley paper's algorithm for lexing? I have no idea, I'll try to reach them and ask the question. > > Here is a nice paper I found googling (in the even absolutely remote > > possibility it might be of interest): > > http://www.google.be/search?q=General+Incremental+Lexical+Analysis+TIM+A.+WAGNER+and+SUSAN+L.+GRAHAM+University+of+California%2C+Berkeley&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a > > ( http://harmonia.cs.berkeley.edu/papers/twagner-lexing.ps.gz ) > i find it extremely complicated. it does not seem very obvious indeed, I'll try to have a look if my family life allows me some spare time. Au plaisir, Stanislas. _______________________________________________ antlr-dev mailing list [email protected] http://www.antlr.org/mailman/listinfo/antlr-dev
