Emmanuel Briot <[email protected]> writes: >> For speeding up parsing after minor editing, we could cache the parser >> state every so often; parsing could start from there. And if the change >> is truly local (ie not introducing a "begin"), then the parse state of >> the new code would match the cached parse state after the edit, and >> parsing could stop. > > That's the idea I had at well. Of course, you would cache the state when > there is only a single parser state. What's involved in caching that state, > though, there is a stack of symbols I believe ?
See wisi-parse.el; the parser state is defined by the cl-defstruct wisi-parser-state. So it would be easy to store that in a text property. Deciding where in the parsing to store it would be tricky; after every semicolon? every 'end'? every 100 lines? > That would not speed up the initial parsing though, so the initial display > of the file would still take several seconds. Caching the parser state would actually slow down the initial parsing :(. That motivates not caching very often. > I am actually very tempted to investigated the GLR parser approach for > GPS too, it might help support more languages in the long term. The parser itself was fairly easy to write. One complication is handling the actions when two parallel parsers arrive at the same state; in general, the list of actions that should be executed is different for the two parsers. For wisi-parse, it didn't matter, so I just picked one. I suspect the same would be true for GPS. But it would not be true in OpenToken, which intended for general parsing; that's one reason I have not implemented a GLR parser in OpenToken yet. -- -- Stephe _______________________________________________ Emacs-ada-mode mailing list [email protected] http://host114.hostmonster.com/mailman/listinfo/emacs-ada-mode_stephe-leake.org
