Re: What is the future of Compiler technology?

"Paulo Matos" <pocmatos@gmail.com>
31 Jul 2006 02:38:09 -0400

          From comp.compilers

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]
| List of all articles for this month |
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]


Post a followup to this message

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