Re: generated code

I wrote:


> They want to be able to read the parser generator output as a series
> of functions.


Pietu Pohjalainen replied:
> Yes. This is exactly the point of writing the parser using function
> calls: the next guy, who doesn't know about compiler generator tools
> wants to have the parser implemented in terms that he already knows;
> maybe stepping in the debugger and not wondering why his debugger
> opened a strange file with suffix '.y'.
>
> What 'OO-grammars' give to this picture is added clarity: class
> structure of the parser reflects the grammar structure. However,
> there's no need to restrict possible implementations only to
> hand-implemented static code doing function/method/constructor
> calls. However, once the implementation moves away from this approach,
> its 'steppability' is also reduced.


However, this is exactly what I fear. Some subsequent developer
coming along and fiddling with the readable generated code to hack in
some special case, not realizing that their special case breaks some
other call to the same function that just doesn't happen to be
exercised in this debugging session (or by this set of inputs).


Using a tool (and thus having an obscure ".y" file) prevents those
kind of accidents, because the tool can (and should) check consistency
for you. When your debugger steps you into some file which is
different from what you normally work on, one is supposed to realize,
"Oh, maybe something different and special is happening here; maybe I
should be careful!"


I have the same sympathy for a person who finds that too constraining
that I do for people who don't wear seatbelts. Sure, we can write and
debug our recursive descent compilers by hand. We can also program
our machines in binary. What makes one think that doing it that way
makes for more reliable software?


Similarly, are you really convinced that stepping through input
samples one token at a time is the best way to determine the
correctness of a grammar? I can understand that once one finds a flaw
and is trying to understand where it comes from, one may need to step
through a little to see "where" the code is going wrong. However,
that should generally be one of the last tasks one does and shouldn't
have to do so on a regular basis. I can probably count on one hand
the number of times I have stepped through the parsing of Verilog
programs in the parser I wrote. In the last year, I did it just once
when updating the grammar from the 1995 to the 2001 spec and that was
to uncover a typographical error that sent a parse down "the wrong
path". I did make and fix other errors, but none by stepping through
the parsing of sample inputs. Most of my errors were found by the
warnings the tool I was using gave me.


I have nothing against recursive descent as an implementation
technique as the output of a tool (other than it can lead to the
acceptance of hand-written recursive descent compilers). Hoever, I
think it is irresponsible to recommend hand-writing recursive descent
parsers. It leads to shoddy programming.


End of tirade.


My apologies if this attack is too harsh or seems too personal. It's
just something I feel strongly about, so excuse me if my objectivity
is blurred in this case. It's just that the flaws of hand-written
code are so blatant to me and I don't understand why people don't see
the obvious.


-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------
[If you hadn't said it, I would. Writing code to make it easy for people
who don't understand it to make arbitrary changes does not strike me as a
winning strategy. -John]

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