[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: |
Thu, 29 Jan 2015 10:32:44 +0100 |
Hello,
> What version of Bison are you using?
2.6.5 and 3.0.2. I plan on installing 3.0.4 before too long.
> prefix I guess.
No, I actually meant a suffix, e.g., MESSAGE_YY, MESSAGE_ZZ, MESSAGE_XX for
tokens in three different parsers. I was assuming that the tokens were defined
as preprocessor macros. I think this was once the case, but I'm not completely
sure. At any rate, I've now checked and found that they are not now.
> The %union types _are_ different, I don't understand what
> you mean.
In the past, I had a problem when using different union declarations in the
different parsers. I just tried changing one and I didn't have a problem. I
don't quite understand how this is working, but it doesn't really matter, if I
can get my program to work using `%define api.prefix'.
> I personally declare YY_DECL myself, I don't trust Flex's
> Bison bridge.
Okay, I'll try this. It sounds like it should work.
Thanks,
Laurence
> Gesendet: Donnerstag, 29. Januar 2015 um 09:44 Uhr
> Von: "Akim Demaille" <address@hidden>
> An: "Laurence Finston" <address@hidden>
> Cc: "Bison Bugs" <address@hidden>
> Betreff: Re: Problem with multiple parsers
>
>
> > Le 28 janv. 2015 à 14:59, Laurence Finston <address@hidden> a écrit :
> >
> > Hello,
>
> Hi!
>
> What version of Bison are you using?
>
> > I've used multiple parsers in a few projects using the `%name-prefix'
> > option. Some other files included more than one of the generated header
> > files which meant that the %union type had to be the same for all the
> > parsers. However, in practice, this wasn't a problem. In addition, I use
> > a suffix
>
> prefix I guess.
>
> > for all token declarations so that there's no interference between tokens
> > from the different parsers or between tokens and other macros.
> >
> > I am also generating a reentrant parser and using locations so the
> > declaration of, e.g., zzlex
> > is:
> >
> > int
> > zzlex(YYSTYPE* value,
> > YYLTYPE* location,
> > yyscan_t parameter);
> >
> > I just noticed that `%name-prefix' is now deprecated, so I tried to use
> > `%define api-prefix' instead. In the Flex code for the scanners, I use
> > `%option prefix' (as before).
> >
> > Everything works fine with `%name-prefix'. When I try to use `%define
> > api-prefix' instead, I get an error when linking:
> >
> > undefined reference to `zzlex(ZZSTYPE*, ZZLTYPE*, void*)'
> >
> > Flex doesn't define ZZSTYPE or ZZLTYPE. I've tried various things, but
> > none of them worked.
>
> Flex does not define ZZSTYPE etc., Bison generates them.
>
> > Does anyone know a solution for this problem?
> >
> > I was happy with `%name-prefix' but I don't want my code to depend on it if
> > it may be removed at some point. It would also be nice if the %union types
> > in the different parsers could be different.
>
> The %union types _are_ different, I don't understand what
> you mean.
>
> I personally declare YY_DECL myself, I don't trust Flex's
> Bison bridge.
>
- 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 <=
- 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, 2015/01/30
- Re: Problem with multiple parsers, Akim Demaille, 2015/01/30