|yacc or bison? email@example.com (1992-04-15)|
|Re: yacc or bison? firstname.lastname@example.org (1992-04-16)|
|Re: yacc or bison? email@example.com (1992-04-22)|
|Re: yacc or bison? firstname.lastname@example.org (1992-04-22)|
|From:||email@example.com (Brian Bliss)|
|Organization:||UIUC Center for Supercomputing Research and Development|
|Date:||Wed, 22 Apr 1992 16:32:56 GMT|
In article 92-04-103, firstname.lastname@example.org (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.
Return to the
Search the comp.compilers archives again.