[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with multiple parsers
From: |
Laurence Finston |
Subject: |
Re: Problem with multiple parsers |
Date: |
Fri, 30 Jan 2015 15:40:45 +0100 |
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?
> >
> >
> >
- Problem with multiple parsers, Laurence Finston, 2015/01/28
- Re: Problem with multiple parsers, Akim Demaille, 2015/01/29
- Re: Problem with multiple parsers, Laurence Finston, 2015/01/29
- Re: Problem with multiple parsers, Akim Demaille, 2015/01/29
- Re: Problem with multiple parsers, Laurence Finston, 2015/01/30
- Re: Problem with multiple parsers, Akim Demaille, 2015/01/30
- Re: Problem with multiple parsers, Laurence Finston, 2015/01/30
- Re: Problem with multiple parsers, Akim Demaille, 2015/01/30
- Re: Problem with multiple parsers,
Laurence Finston <=
- Re: Problem with multiple parsers, Akim Demaille, 2015/01/30