Related articles |
---|
[3 earlier articles] |
Re: Do we need parsers? monnier+/news/comp/compilers@tequila.cs.yale.edu (Stefan Monnier) (1997-05-17) |
Re: Do we need parsers? monnier+/news/comp/compilers@tequila.cs.yale.edu (Stefan Monnier) (1997-05-17) |
Re: Do we need parsers? thetick@scruz.net (Scott Stanchfield) (1997-05-19) |
Re: Do we need parsers? David.Monniaux@ens-lyon.fr (1997-05-22) |
Re: Do we need parsers? john@dwaf-hri.pwv.gov.za (John Carter) (1997-05-22) |
Re: Do we need parsers? nkramer@jprc.com (Nick Kramer) (1997-05-30) |
Re: Do we need parsers? dgay@barnowl.CS.Berkeley.EDU (1997-06-04) |
From: | dgay@barnowl.CS.Berkeley.EDU (David Gay) |
Newsgroups: | comp.compilers |
Date: | 4 Jun 1997 22:46:41 -0400 |
Organization: | University of California, Berkeley |
References: | 97-05-158 97-05-323 |
Keywords: | parse, design |
Nick Kramer <nkramer@jprc.com> writes:
I've heard of two general approaches to this problem. One is to write
a hybrid structure/text editor. Above some granularity, usually
statements or expressions, you use tree operations. Below that
granularity, the editor acts like a normal text editor. The other
approach is to give the user what looks like a normal text editor, but
then re-parse the program with every keystroke (using fancy
incremental lexing and parsing algorithms to make this computationally
feasible).
The Gwydion Project has been prototyping a variation on the first
approach.
For an example of the second approach, check out the 'Ensemble'
project (http://HTTP.CS.Berkeley.EDU/Research/Projects/ensemble/) at
Berkeley - I'm not really up on the details, but it does incremental
lexing and parsing for just these reasons.
--
David Gay - Yet Another Starving Grad Student
dgay@cs.berkeley.edu
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.