Hello, > My current project is for my work and I'm not allowed to publish any code. > However, I used three scanner/parser pairs in a > recent project for my previous job and it can be downloaded from Github: > https://github.com/gwdg/gwrdifpk
I should have mentioned that the scanner and parser code is in the following files in the /gwrdifpk/src directory: scanner.web scnrclnt.web scnrcln2.web parser.web prsrclnt.web prsrcln2.web It was also a fairly complex project, so I doubt that would be worth the effort of trying to get it to build. There is a manual in the gwrdifpk/doc, however, in case anyone is interested. Laurence > Gesendet: Freitag, 30. Januar 2015 um 15:21 Uhr > Von: "Laurence Finston" <laurence.fins...@gmx.de> > An: "Akim Demaille" <a...@lrde.epita.fr> > Cc: "Bison Bugs" <bug-bison@gnu.org> > Betreff: Re: Problem with multiple parsers > > Hello, > > > yes, that would be nice. Or if you have a tarball we could > > have a look at. > > My current project is for my work and I'm not allowed to publish any code. > However, I used three scanner/parser pairs in a recent project for my > previous job and it can be downloaded from Github: > https://github.com/gwdg/gwrdifpk > > > Yes, but is this really what you want? You are giving > > credential blindly to any scanner. Shouldn't you just > > pinpoint to the one you actually use? > > No, it's definitely not what I want. I would rather have a friend > declaration for each one and I'd like the types of *STYPE and *LTYPE > arguments to be completely distinct and not have typedefs or #defines making > one a synonym of another. > > This friend declaration is in the declaration for the class that I use for > the parameter that I pass to each of the scanners and parsers, so it is > desirable for all of the scanner and parser functions to be its "friends". > > > So far, so good. You are mixing together different entities > > with the same name, that's risky business. So far, I consider > > the api.prefix approach better. > > I would prefer it, too, if I could get it to work. The problem seems to be > that Bison and Flex use the prefix for some but not all of the typenames, > variables, macros, functions, and whatever else they define. > > > Are you sure your problem is with Bison and not flex? > > I would say it's a problem with the way Bison and flex work together. > > The solution I found with %name-prefix is definitely not ideal, but I haven't > been able to get it to work with `%define api.prefix' at all yet. > > Laurence > > > Gesendet: Freitag, 30. Januar 2015 um 14:40 Uhr > > Von: "Akim Demaille" <a...@lrde.epita.fr> > > An: "Laurence Finston" <laurence.fins...@gmx.de> > > Cc: "Bison Bugs" <bug-bison@gnu.org> > > Betreff: Re: Problem with multiple parsers > > > > > > > Le 30 janv. 2015 à 11:30, Laurence Finston <laurence.fins...@gmx.de> a > > > écrit : > > > > > > Hello, > > > > Hi Laurence, > > > > > I tried defining YY_DECL as you suggested, but I still couldn't get it to > > > work. The program is already fairly complex so it's not easy to test > > > just the problem of getting multiple parsers to work together. If I find > > > the time, I'll try to set up a minimal example. > > > > yes, that would be nice. Or if you have a tarball we could > > have a look at. > > > > > One problem is a `friend' declaration in a class declaration: > > > > > > friend int yylex(YYSTYPE*, YYLTYPE*, yyscan_t); > > > > > > (I'm generating C scanners and parsers and using them in a C++ program.) > > > > > > Using `%name-prefix', this works for the other scanners (xxlex and > > > zzlex), too. That is, this single `friend' declaration works for all > > > three scanner functions. > > > > Yes, but is this really what you want? You are giving > > credential blindly to any scanner. Shouldn't you just > > pinpoint to the one you actually use? > > > > friend int yylex(ZZSTYPE*, ZZLTYPE*, yyscan_t) > > > > (I don't know for the last one, it is not under the control > > of Bison). > > > > > When I try to use `%define api.prefix', I get various errors pertaining > > > to YYSTYPE, YYLTYPE, > > > > So far, so good. You are mixing together different entities > > with the same name, that's risky business. So far, I consider > > the api.prefix approach better. > > > > > YY_DO_BEFORE_ACTION, YY_NEW_FILE, etc. > > > > This, I don't understand. It has nothing to do with Bison. > > > > Are you sure your problem is with Bison and not flex? > > > > > >
