Re: WANTED: stylistic advice/guidelines for YACC and LEX

timd@Starbase.NeoSoft.COM (TimD) writes:
> (1) For example, when I write a spec with an action, I try to
> put the action code in a subroutine. Compare:
>
[snip]


> To me, the benefits of doing this are:
>
> 1) the yacc spec is shorter (more modular) and easier to read.
> 2) when stepping through the code in a debugger, it is easier
> to tell where you are.


Those are exactly my reasons for always trying to put the action code
in a separate function. Point number 2 can be a biggie, depending on
how the debugger handles the #line directive. My yacc sticks in #line
directives by default and I usually wind up having to turn it off to
debug. That directive seems to confuse some source level debuggers.


Another thing that I have thought about for a while is using function
pointers in the action code instead of a hardwired function call. It
seems that you could do some really interesting things by being able
to specify the semantic actions dynamically. I like the idea of a
"library" parser that could have its actions customised for a specific
application. Too bad I can't think of a good use for it. Have you ever
seen anything like that? I haven't. A similar thought that I have had
(for C++ programs) is to implement the action code as virtual members
of the parser class. MKS yacc gives you the option of creating the
parser as a C++ class. You could take the class that yacc generates
and add virtual functions for each semantic action. That is another
one that I can not think of a use for. Can you?


Bob.
--

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