|Is LALR(1) or LL(k) parser better for C++ firstname.lastname@example.org (1997-01-22)|
|Re: Is LALR(1) or LL(k) parser better for C++ email@example.com (John Lilley) (1997-01-22)|
|Re: Is LALR(1) or LL(k) parser better for C++ firstname.lastname@example.org (David L Moore) (1997-01-25)|
|Re: Is LALR(1) or LL(k) parser better for C++ email@example.com (Scott Stanchfield) (1997-01-26)|
|Re: Is LALR(1) or LL(k) parser better for C++ firstname.lastname@example.org (1997-01-26)|
|Re: Is LALR(1) or LL(k) parser better for C++ email@example.com (David L Moore) (1997-01-29)|
|From:||David L Moore <firstname.lastname@example.org>|
|Date:||29 Jan 1997 12:06:10 -0500|
|References:||97-01-163 97-01-181 97-01-206 97-01-209|
Scott Stanchfield wrote:
> Just a note here -- the "$$ variables" in yacc actually get turned into
> references like yypvt. Depends on the yacc you're using. In some, the
> $1, $2, $3 are represented by (if you just reduced something like a: b c d)
> yypvt -- most recent ($3)
> yypvt[-1] -- next back ($2)
> yypvt[-2] -- next back from that ($1)
> and so on. Basically, yypvt is a pointer into the stack where all the
> fun happens. But beware -- this can change based on the yacc you're
Indeed, but you have to work out the mapping and then TYPE IT IN
rather than just double clicking.
An alternative is to remove all the #line directives from the x.tab.c
file. Your debugger will then throw up x.tab.c rather than thing.y as
the source code. The only trouble with this is that now it is hard to
work out what production you are in. (If you leave the LINE directives
as comments you can bring up the .y file in a separate window and go
to the line to find the production)
Those $1, $2 etc are a real pain when you change a production - you
have to go through and renumber. It would be much easier if you could
add a label to each item in a production. In an MSP parser I wrote
many years ago (pre-yacc), you could write "Ident.A = TypeId.type
Ident.B" and then use A and B rather than $0 and $2. (A:Ident might
have been better) This might solve the debug problem too.
I wonder how well MSP would work on C++ :-) ?
> Have a look at PCCTS -- look at
Funny you should mention that.....
Return to the
Search the comp.compilers archives again.