|Syntax directed program editing firstname.lastname@example.org (1992-02-05)|
|Re: Syntax directed program editing email@example.com (1992-02-06)|
|Re: Syntax directed program editing firstname.lastname@example.org (1992-02-15)|
|Re: Syntax directed program editing nickh@CS.CMU.EDU (1992-02-07)|
|Re: Syntax directed program editing email@example.com (1992-02-07)|
|Re: Syntax directed program editing firstname.lastname@example.org (1992-02-07)|
|Re: Syntax directed program editing email@example.com (1992-02-11)|
|From:||firstname.lastname@example.org (David Keppel)|
|Organization:||Computer Science & Engineering, U. of Washington, Seattle|
|Date:||Thu, 6 Feb 92 16:20:07 GMT|
email@example.com (Richard Brooksby) writes:
>[Most compilers spend half their time lexing/parsing input.
> Why no editors directly on the parse trees?]
Most compilers on Un*x platforms spend the other half of their time (:-)
generating assembly and then lexing and parsing assembly.
Editing the parse trees is one way to make recompiles go fast. Another
way is to make the unit of recompilation quite small. The latter approach
is used quite successfuly in the Smalltalk-80 programming environment.
Only one method (procedure) needs to be recompiled at a time.
Recompiles tend to be ``nearly instant'' even though (a) the compiler is
not particularly optimized for speed and (b) it is written in
Smalltalk-80, which benchmarks at about 10% the performance of C. It is
also the case that the compiler does little work compared to a normal
compiler, since the bytecode output can be generated easily from the
input; yet with half the compiler time spent in lexing and parsing you
would expect the compiler to run at most twice as fast, bringing it to
perhaps 20% the speed of a C compiler.
When doing ``large compiles'' (recompiling all of a program from scratch)
both approaches will need to lex and parse the input.
;-D on ( Bafflingly easy solutions ) Pardo
Return to the
Search the comp.compilers archives again.