|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)|
|Date:||Thu, 16 Apr 1992 13:57:41 GMT|
email@example.com (Paul Keddie) writes:
>[what are relative merits of yacc, bison, etc.]
Well, I have not used Bison, but I can certainly put my 2 cents in about
It is avaliable pretty much in pure form on all systems. It works well
It allows productions to "return" values, but does not allow the "passing"
of values to productions. This makes some things VERY difficult to
manage. Global variables abound.
You can not easily use 2 yacc descriptions in the same program. This
really bit me once when a library I was using used yacc when I wanted to.
Totally bogus. Lex is the same way. I am amazed that Lex and Yacc have
not been fixed to this day.
It is very difficult to determine why a grammar might be ambiguous. A
debugging file can be printed out, but it looks like gibberish. It seems
that an English description of ambiguities could be printed out, but is
Yacc code does not lint cleanly.
[Inherited attributes can often be handled using the $0 and $-1, Bison and
Posix yacc address the multiple parser problem by letting you change the
"yy" prefixes in the generated parser via command line switches. There
are variety of ways to fake it with older versions of yacc, see messages
90-08-085, 90-09-029, 90-09-007, 90-08-076, and 90-08-101. -John]
Return to the
Search the comp.compilers archives again.