Re: Using Bison to Build Multiple Parsers in the Same Application
Re: Using Bison to Build Multiple Parsers in the Same Application
- Subject: Re: Using Bison to Build Multiple Parsers in the Same Application
- From: Wim Lewis <email@hidden>
- Date: Mon, 21 Feb 2011 14:34:10 -0800
On 19 Feb 2011, at 5:28 AM, Thomas Wetmore wrote:
> A long time problem with yacc is that it uses global name space which prevents a single application from holding two or more generated parsers. [....]
>
> 1) Are there any Cocoa and bison experts out there who have found workable solutions to the problem of having multiple parsers in the same application.
For the filename, you can go to the "Yacc - Build Options" section of the target settings and change the "Generated File Stem" to "Input file stem". (Or in an xcconfig file, set YACC_GENERATED_FILE_STEM = InputFileStem). Why this is not the default I have no idea.
You can avoid symbol clashes by:
1. Make sure you're generating a pure parser, e.g. %pure_parser
2. Implement yylex() and yyerror() as static functions in the prologue/epilogue sections of the .ym file
3. #define yyparse NonCollidingEntryPointName in the prologue
With these settings, the only externally visible symbol is NonCollidingEntryPointName().
(According to the Bison docs, you could use the '-p PREFIX' option or the '%name-prefix "PREFIX"' directive instead of #defining yyparse, and Bison will insert the #define for you. I haven't tried it.)
> 3) Are there any other parser generators in common use in Mac OS X applications that don't have the problems caused by bison's and yacc's ancient reliance on global name spaces?
ANTLR and Dparser are two packages that look nice. I haven't used them but I intend to look at them next time I write a nontrivial parser; they're a bit newer and probably don't have the 1980s compatibility constraint that Bison does. On the other hand, using Bison means I don't need to configure and maintain yet another large third-party tool in my build chain, and Bison has always worked quite well for me.
For simpler languages which can be parsed by a finite automaton or a slightly augmented finite automaton, I really like Ragel, which is a state-machine compiler.
http://www.antlr.org/
http://dparser.sourceforge.net/
http://www.complang.org/ragel/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden