|History of code completion firstname.lastname@example.org (2001-10-20)|
|Re: History of code completion email@example.com (Lex Spoon) (2001-10-21)|
|Re: History of code completion firstname.lastname@example.org (2001-10-23)|
|Re: History of code completion email@example.com (Jan Gray) (2001-10-23)|
|Re: History of code completion firstname.lastname@example.org (2001-10-23)|
|Re: History of code completion email@example.com (Geoff Wozniak) (2001-10-27)|
|Re: History of code completion firstname.lastname@example.org (Marco van de Voort) (2001-11-05)|
|Re: History of code completion email@example.com (2001-11-08)|
|Re: History of code completion firstname.lastname@example.org (Richard Heathfield) (2001-11-08)|
|[4 later articles]|
|From:||email@example.com (Neelakantan Krishnaswami)|
|Date:||23 Oct 2001 20:20:43 -0400|
|Posted-Date:||23 Oct 2001 20:20:43 EDT|
On 21 Oct 2001 21:30:13 -0400, Lex Spoon <firstname.lastname@example.org> wrote:
> This style is used in VB and Smalltalk, and it's used in syntax
> highlighters in, e.g., Emacs. The syntax highlighters in particular
> often rely on heuristics instead of doing strictly correct parses, at
> least if the current buffer has unsyntactic code in it. I honestly
> don't know whether this is due to theoretical limitations or just due
> to a lack of effort by the authors.
Tim Wagner's PhD thesis at Berkeley in 1997 was the design of an
incremental GLR parser that could identify and efficiently manage
syntactically incorrect regions in parts of the parse tree:
This was done as part of the Ensemble (now Harmonia) project for
building extensible development environments. There was also work on
incremental lexing done, of course.
Once you have the parse tree, the next question is what kinds of
semantic analysis you can offer the user. Online typechecking is
obvious, and even highlighting which compiler optimizations are
feasible with a given code structure is possible.
I've only really seen two example of this. First is the refactoring
browser. The other one is the Dylan compiler from Functional Objects,
which has an IDE that highlights method calls to identify which method
dispatches the compiler is able to optimize away. This lets you
visually identify whether you have a lots of dynamic dispatching in a
critical inner loop, for example. It's very neat.
Return to the
Search the comp.compilers archives again.