Re: What is the future of Compiler technology?

Gabriel Dos Reis wrote:


> | [I don't think I've ever seen an application where the parser took
> | enough time to worry about. Lexer performance is much more important
> | since the lexer is the only part of the compiler that has to look at
> | each character of the input program. -John]
>
> From experience, the performance of the GCC/g++ *parser* had worried
> and continue to worry users and corporate that base their system
> compilers on it.


Remember how this thread started.
We were actually talking about generated parsers.


> Jürgen Kahrs wrote:
>> > Oliver Zeigermann wrote:
>> >
>>> > > your "ordinary" programmer. This requires compiler generators to be
>>> > > easier to use and understand. Who *really* understands yacc?
>> >
>> > We already _have_ compiler generators which are easier to understand
>> > than yacc. Look at CoCo/R. Many others are available.
>
> Do you know if there are any studies on the performance of the
> resulting parser in C++ against 'traditional' tools? (There are
> probably many studies...)


The focus was on parsers which are generated and readable. A parser
generated by CoCo/R initially only _parses_ some text and does it
blazingly fast. Performance is _never_ an issue. But when you do more
than just syntax-guided parsing (like saving context, generating
code), than performance may be an issue. But this is not about parsing
performance anymore.

Return to the comp.compilers page.
Search the comp.compilers archives again.