Re: yacc or bison?

In article 92-04-103, graham@maths.su.oz.au (Graham Matthews) writes:
|> (Paul Keddie) writes: [relative merits of yacc, bison, etc?]
|>
|> There is one other consideration that may be relevant, and that is that
|> Bison in combination with Flex can be used to generate re-entrant code.
|> In some applications (eg: where your language allows a load library
|> command for example, and a library can itself contain another load
|> library command ...] this re-entrancy is very useful.


I've used (use) bison and flex to generate a re-entrant parser that can be
invoked in parallel - I had to hack on the flex (v 2.3.6) skeleton parser
"flex.skel", and put most of the global variables (well, declared static -
local to the compilation unit) it uses into a record structure which is
passed in as an argument at every call. In the standard PDA/DFA
parser/lexer scheme, the parser is called and does not return until
parsing is done, whereas the lexer is invoked and returns repeatedly; its
state must be stored somewhere outside of it's stack frame - Does a an
object-oriented lexical analyzer exist?


Now bison, on the other hand, is entirely re-entrant (if YYPURE is NOT
#defined - doesn't that seem backwards?)


One trick you can use is to take the lex/flex-generated lexer, and
automatically rename all the identifiers with a substitution of the "yy"
and "YY" prefixes, so that a given number of lexers may be used in the
same executable, but that doesn't make it re-entrant.


bb
--

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