Re: Compiler Books? Parsers?

On 2003-12-04, Chris F Clark <cfc@shell01.TheWorld.com> wrote:
>
> This is trivially true, if one considers the fact that one can take the
> output of any given tool and then profile and modify it so that the
> resulting hand-written tool is faster.
>
> However, in contrast, if someone figures out how to write a faster
> output for a specific tool, you may have to rearchitect your
> hand-tweaked to take advantage of those improvements. Note, that
> that doesn't happen very often (in 15 years of working on a tool,
> there were approximately 4 times where we specifically worked on
> speeding the generated parsers up).


Interesting, if the main reason to chose handcoded tools is speed.


What if it was quality of error generation? Could you argue your case if
my primary objective was error generation?


> (and even there certain lexical errors typically destroy the
> parsers ability to recover). They do not do a good job at
> generating parsers that can pick fragments of correct code out of a
> sea of garbage, nor any other tasks they weren't designed to do.
> But, note that some parser generators (e.g. Quinn Tyler Jackson's
> meta-S) are now beginning to support a grep-mode, which may solve
> that problem.


I don't mind as much. Simply issueing an error for "strange" output is
enough. What if I'm more interested in the viewpoint of a user to fix
bad programs (to be parsed by my parser), what would you do?

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