3

The manual clearly says: 

YYSETSTATE (s)

[...]
The parameter to YYSETSTATE is a signed integer that uniquely identifies
the specific instance of YYFILL (n) that is about to be called.
[...]

The problem is, I'm calling my YYSETSTATE defined macro from a bison parser. How can I begin a state without knowing the integer UI? In other words, how can I get the identifier of a state I want to begin.

On lexer:

<MY_STATE>{NAME} {
    return FN_NAME;
}

On parser:

expr: { push_state( ? ) } /* what's the identifier of MY_STATE? */
    '(' FN_NAME VALUE VALUE ')' { compile_expr($2, $3, $4); }
;
marcio
  • 10,002
  • 11
  • 54
  • 83
  • YYSETSTATE and YYFILL are part of the `re2c` interface, afaik. What manual are you quoting from? – rici Feb 07 '15 at 07:41

1 Answers1

3

I don't think you should ever invoke the YYSETSTATE macro. It's used as part of re2c's control-inversion mechanism, enabled with the -f command-line flag, which turns the scanner into a "push" scanner. That's a handy feature, but it has nothing to do with start conditions, and it's hard to imagine a circumstance in which you could break through the abstraction to directly set the state.

re2c does have a feature similar to flex's start conditions, which is enabled with the -c command-line flag. To set the current condition, you use YYSETCONDITION, which takes a value from an enumeration of start conditions. If you also supply the -t command-line flag, re2c will create a header file with this enumeration, so that you can perform YYSETCONDITION from other translation units.

rici
  • 234,347
  • 28
  • 237
  • 341
  • I ended up with a better solution but in fact I needed to generate the headers and include the generated header files. I accepted this answer but I also don't encourage this approach. – marcio Feb 09 '15 at 07:09
  • @marcio: Wasn't the answer clear enough that you would need to generate and include headers if you were going to use `SETCONDITION`? And what is it about "this approach" which you don't encourage (aside from the fact that it is unnatural backchannel from the parser to the lexer)? Or, better asked, "this approach to *what problem*?" :) – rici Feb 09 '15 at 07:22
  • Your answer is perfect. The approach I'm referring to is passing information from parser to the lexer. In my specific case there was a much better way to do it :) – marcio Feb 09 '15 at 07:44