[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.technology.imp] Re: Incremental parsing

Lennart J wrote:
Hi Newsgroup,

I am pretty new to IMP and LPG so please bare with me if this is newbi questions.

As far as I understand it is possible to do incremental parsing with LPG, but I guess
that the EBNF (.gi, .g files) must have been written in some special way to handle this?
I guess also that one need to tell the parser that the passed source is not a complete compilation unit?


Can someone please explain this to me.

In principle, the idea is to:

 - Instruct the parser generator to provide multiple "entry points" to the
   parser, one for each construct that might be re-parsed. E.g., for Java,
   the entry points would be something like types, methods, blocks.

   Recent versions of LPG (say, 2.0.15 or so and later) allow one to specify
   multiple start symbols in the "%Start" segment.

 - Figure out the innermost such construct that contains the editing
   "damage", and call the appropriate parser entry point.

 - Knit the AST produced for the fragment just parsed into the existing
   AST. The manner of doing this would be specific to the kind of AST
   being produced. There's no specific support for this in LPG-generated
   ASTs, but there's also nothing in their design that (AFAIK) should
   prevent it or make it difficult.

That said, I don't think we have quite enough API in IMP to really take
advantage of this. In particular, I don't think there's any API yet to
pass the damage region into the parser.

On the other hand, it's certainly something we've been wanting to do for
long enough that if people express enough interest, I'd definitely be
willing to work to add whatever's needed in the relatively near term.

--
Cheers,
  -- Bob

--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center

IDE Meta-tooling Platform Project Lead (http://www.eclipse.org/imp)
X10: Productive High-Performance Parallel Programming (http://x10.sf.net)