Re: Compiler Books? Parsers?

>[Automation also wins for accuracy. You can be quite confident that
>the parser that yacc or another generator writes for you parses
>exactly the grammar you gave it, but it's very easy to leave
>undiagnosed holes in a hand-written RD parser. -John]


Yes and no and kind of. The key problem is having to transform the
representation used in design to the one needed for implementation.
If that transformation isn't trivial, it's easy to make mistakes in
it.


But I think this problem can hit you even in the automation case. If
the automation has serious constraints on what it will accept, or you
used an eccentric design notation, the transformation can be
non-trivial even though both are grammars.


(As a case in point, it was not until 1984 -- hmm, might have been
1983, my memory is a bit vague -- that there was an LALR(1) grammar
for C. Even though C had been described using grammars since its
origins in the early 70s, writing a *correct* LALR(1) grammar for it
was hard. Steve Johnson's late-70s PCC did use a yacc parser, but
cheated a lot. In particular, PCC refused to accept a number of
unusual syntactic forms that were officially legal C. This was not
something you could discover by a quick comparison of the yacc grammar
to the C Reference Manual grammar.)
--
MOST launched 30 June; first light, 29 July; 5arcsec | Henry Spencer
pointing, 10 Sept; first science, early Oct; all well. | henry@spsystems.net

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