|any lex/yacc debuggers???? firstname.lastname@example.org (2002-04-06)|
|Re: any lex/yacc debuggers???? email@example.com (Scott Nicol) (2002-04-07)|
|Re: any lex/yacc debuggers???? firstname.lastname@example.org (Kamal R. Prasad) (2002-04-07)|
|Re: any lex/yacc debuggers???? email@example.com (Scott Nicol) (2002-04-10)|
|Re: any lex/yacc debuggers???? firstname.lastname@example.org (Scott Nicol) (2002-04-13)|
|Re: any lex/yacc debuggers???? email@example.com (Lex Spoon) (2002-04-29)|
|From:||Lex Spoon <firstname.lastname@example.org>|
|Date:||29 Apr 2002 01:55:06 -0400|
|Organization:||Georgia Institute of Technology|
|References:||02-04-034 02-04-047 02-04-057 02-04-063 02-04-075|
|Posted-Date:||29 Apr 2002 01:55:06 EDT|
"Scott Nicol" <email@example.com> writes:
> > [If you turn on YYDEBUG in Berkeley yacc, you get a blow by blow report
> > on what tokens it reads, what state it shifts into, and what rules it
> > reduces. The info is all there if you wanted tart it up into a video
> > debugger. -John]
> It tells you state numbers. That's all well and good - every YACC
> I've seen tells you that. It just doesn't tell you what those state
> numbers mean (i.e. I'm at this point in this rule), nor does it tell
> you what valid tokens follow next.
For what it's worth, I'm pretty sure ml-yacc will list precisely this
information in its debug traces. It doesn't seem like it would be
hard to add at least that much help to an existing yacc, though it may
well increase the size of a debug-enabled executable.
In fact, I didn't really grok how the LR stack machine works until I
read through some of this trace information from ml-yacc. Previously
I would just read the grammar and treat the parsing algorithm as
magic. Thus, trace information of this kind can be a good educational
tool as well as a debugging aid.
Return to the
Search the comp.compilers archives again.