bison's doc [...] tells that I must add %define api.prefix {PREFIX} on eval.y,

Well yes, but that's an enabler, not a complete solution. The docs go on to describe the effects of such a definition:

Specifying ‘%define api.prefix {prefix}’ [...] renames the interface functions and variables of the Bison parser to start with prefix instead of ‘yy’, and all the macros to start by PREFIX (i.e., prefix upper-cased) instead of ‘YY’.

In other words, you also have to change all the YY* symbols appearing explicitly in the parser definition file and the corresponding lexer definition file correspondingly, to use your specified alternative prefix instead of YY.

And that should make sense to you if you pause to consider. The nature of the problem to be solved is that Bison and Flex (following from Yacc and Lex) interact in part via external functions and variables, and via macro definitions, with pre-defined standard names. If you want to include two such parsers in the same program, then that produces a variety of name collisions. Avoiding / fixing those collisions is the main task. Bison and Flex definition files contain a variety of sections that are specified to be copied verbatim to the generated C files and headers, and those need to use the appropriate names.

Much the same applies to Flex's %option prefix="PREFIX"’, which

changes the default ‘yy’ prefix used by flex for all globally-visible variable and function names to instead be ‘PREFIX’. For example, ‘--prefix=foo’ changes the name of yytext to footext. It also changes the name of the default output file from lex.yy.c to lex.foo.c.

Thus, for example, the prototype for yylex() in your grammar file has problems from both directions:

• on one hand, the YYSTYPE and YYLTYPE macros appearing in its parameter list don't correspond to anything Bison will generate under the circumstances. They need to be PREFIXSTYPE and PREFIXLTYPE instead.

• on the other hand, it's a prototype for the wrong function altogether. The scanner function Flex will generate under the circumstances will be named prefixlex().

Is there a way to fix this?

Yes. Update the scanner and lexer definition files to match the prefix you assign. Just designating a different prefix is not enough.

Or, is the api.prefix broken on bison?

No. The behavior you show is consistent with Bison behaving as documented.