Re: Problem with multiple parsers

[Laurence Finston]

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" <address@hidden>
> An: "Akim Demaille" <address@hidden>
> Cc: "Bison Bugs" <address@hidden>
> 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" <address@hidden>
> > An: "Laurence Finston" <address@hidden>
> > Cc: "Bison Bugs" <address@hidden>
> > Betreff: Re: Problem with multiple parsers
> >
> > 
> > > Le 30 janv. 2015 à 11:30, Laurence Finston <address@hidden> 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?
> > 
> > 
> >