|Writing a recursive descent parser in C email@example.com (2001-11-29)|
|Re: Writing a recursive descent parser in C firstname.lastname@example.org (2001-12-03)|
|Re: Writing a recursive descent parser in C email@example.com (Joachim Durchholz) (2001-12-07)|
|Re: Writing a recursive descent parser in C firstname.lastname@example.org (Bill Rayer) (2001-12-07)|
|Re: Writing a recursive descent parser in C email@example.com (SLK Parsing) (2001-12-07)|
|Re: Writing a recursive descent parser in C firstname.lastname@example.org (2001-12-11)|
|Re: Writing a recursive descent parser in C email@example.com (2001-12-11)|
|From:||"Joachim Durchholz" <firstname.lastname@example.org>|
|Date:||7 Dec 2001 23:35:28 -0500|
|Posted-Date:||07 Dec 2001 23:35:28 EST|
Edward G. Nilges <email@example.com> wrote:
> [Good explanation of handcoded recursive descent parsing snipped]
> Effective implementations of transactioning support it with an
> unlimited stack inside the data base engine, which makes it an obvious
> choice in a recursive descent parser, which is using the runtime stack
> (of C or other runtime) to track its position in the grammar.
> If you do not have a data base, then you need to think about what the
> "output" routines of your compiler do. Your symbol table should be
> able to checkpoint and rollback, as should your machine code
"Transactions with a stack" are named "nested transactions" in the
Note that using a database to make the data structures undoable can
become a bit heavyweigth.
Also, mapping database data structures to in-memory data and back can be
a PITA (though it's less problematic for C than for languages that make
heavy use of polymorphism).
> In my usual scenario I am generating a stream of code to a reverse
> Polish machine, and at any time, checkpointing is merely noticing
> the size of the generating code, and rollback is re-allocating the
> Polish array back to the saved size.
Much cheaper than writing to a database and rolling back :)
> But as my technically adept and aware boss at Bell-Northern Research
> pointed out to me some time ago, if you have a modern editor, the
> economics of code generation change. You can use cutting and
> pasting more effectively than running some mainframe batch-oriented
> tool which yacc unfortunately is these days.
And if you have a bug, you cut-and-paste it a dozen times, leaving it to
be fixed another dozen times, if you find all the instances again?
C&P is OK for one-shot projects. It's not OK if the code has to be
maintained, no matter what the editor economics is.
Besides, it was *never* difficult to cut and paste. Not even in
mainframe days. Not even in the days of punched cards. So nothing has
changed, even if that boss said so.
[I agree, copying buggy code is hardly a new technique. -John]
Return to the
Search the comp.compilers archives again.