|Fast LR algorithms email@example.com (1991-10-15)|
|Re: Fast LR algorithms firstname.lastname@example.org (1991-10-16)|
|Re: Fast LR algorithms -- yacc open code converter email@example.com (1991-10-17)|
|From:||firstname.lastname@example.org (Mike Haertel)|
|Date:||Tue, 15 Oct 91 09:24:19 PDT|
I've lost count of the number of journal articles I've seen on finding
fast LR(1) algorithms. It seems to be one of the most popular subjects to
write about in the more theoretical reaches of CS.
But, realistically, aren't we losing sight of something here?
I think we should be far more concerned with the speed of the resulting
parsers, than with the speed with which we can produce parsers. Yet,
considering the amount of effort that appears to have been spent on the
two problems, it looks like producing parsers fast is considered far more
important than producing fast parsers!
Consider, for example, Ken Thompson's biggest complaint about his own C
compiler's performance: the yacc-generated parser is by far the slowest
[Good point. I gather that an LL parser generated as open code, e.g. a
mechanically generated recursive descent parser, is a lot faster than
any of the LALR parsers. -John]
Return to the
Search the comp.compilers archives again.