Related articles |
---|
[3 earlier articles] |
Re: What is the future of Compiler technology? tommy.thorn@gmail.com (Tommy Thorn) (2006-07-05) |
Re: What is the future of Compiler technology? torbenm@app-4.diku.dk (2006-07-06) |
Re: What is the future of Compiler technology? oliver@zeigermann.de (Oliver Zeigermann) (2006-07-16) |
Re: What is the future of Compiler technology? Juergen.Kahrs@vr-web.de (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=) (2006-07-16) |
Re: What is the future of Compiler technology? eliotm@pacbell.net (Eliot Miranda) (2006-07-19) |
Re: What is the future of Compiler technology? Colin_Paul_Gloster@ACM.org (Colin Paul Gloster) (2006-07-19) |
Re: What is the future of Compiler technology? pocmatos@gmail.com (Paulo Matos) (2006-07-31) |
Re: What is the future of Compiler technology? gdr@integrable-solutions.net (Gabriel Dos Reis) (2006-07-31) |
Re: What is the future of Compiler technology? Juergen.Kahrs@vr-web.de (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=) (2006-08-03) |
Re: Parser performance, was What is the future of Compiler technology? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-08-03) |
Re: What is the future of Compiler technology? gdr@integrable-solutions.net (Gabriel Dos Reis) (2006-08-04) |
Re: Parser performance, was What is the future of Compiler technology? gdr@integrable-solutions.net (Gabriel Dos Reis) (2006-08-04) |
Re: Parser performance, was What is the future of Compiler technology? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-08-05) |
[7 later articles] |
From: | "Paulo Matos" <pocmatos@gmail.com> |
Newsgroups: | comp.compilers |
Date: | 31 Jul 2006 02:38:09 -0400 |
Organization: | http://groups.google.com |
References: | 06-06-04406-06-055 06-07-023 06-07-031 |
Keywords: | parse, tools, comment |
Posted-Date: | 31 Jul 2006 02:38:09 EDT |
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...)
Turns out that the real question is then: Where can I find them?
Cheers,
Paulo Matos
[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]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.