Akim Demaille wrote: > So **please** take the time to play with this beta,
So far it works well with my parsers. > in particular to > see how these features allow you to get rid of dirty hacks you needed > to customize your error messages (I listed several such examples in > https://lists.gnu.org/r/bison-patches/2020-01/msg00000.html). I haven't used any such hacks, but I might start i14ing my parsers now that it's properly supported. On that subject: > Therefore, by default, error messages now refer to "end of file" > (internationalized) rather than the cryptic "$end", or to "invaid token" Typo: "invaid" (only in NEWS apparently). > rather than "$undefined". > > Therefore in most cases it is now useless to define the end-of-line token > as follows: > > %token T_EOF 0 "end of file" > > Rather simply use "YYEOF" in your scanner. I'd say it depends. My parsers read from files just as well as from command-line arguments (cf. sed/awk) or user input (e.g. an interactive calculator). So I'll keep my slightly more general wording (you might consider making this Bison's default, but I guess it'd be an unexpected spurious change to some users): %token END 0 "end of input" > **** Token aliases internationalization > > When the %define variable parse.error is set to `custom` or `detailed`, > one may specify which token aliases are to be translated using _(). For > instance > > %token > PLUS "+" > MINUS "-" > <double> > NUM _("double precision number") > <symrec*> > FUN _("function") > VAR _("variable") > > In that case the user must define _() and N_(), and yysymbol_name returns > the translated symbol (i.e., it returns '_("variable")' rather that > '"variable"'). In Java, the user must provide an i18n() function. I've used GNU gettext, but not those (strange IMHO) macros with it, so I had to find out what to define them to. You might want to elaborate a bit on that. In examples/c/bistromathic/parse.y I see just: #define N_ #define _ If I do that, I get the compiler warning: error: this condition has identical branches [-Werror=duplicated-branches] about: return (yysymbol < YYNTOKENS && yytranslatable[yysymbol] ? _(yy_sname[yysymbol]) : yy_sname[yysymbol]); Not sure if you consider this a problem, since this seems to be just "nop" i14ing. Looking further in several tests, I found that apparently "N_" (unlike "_") should indeed always be defined as a nop -- but if so, can't the skeleton do this by itself? Also, since I don't use autoblah, it seems I have to define both YYENABLE_NLS and ENABLE_NLS. The former is mentioned in the manual (but only in conjunction with autoblah), the latter not at all. So if I got it correctly now, this seems to be the minimum required for i18n, apart from the bindtextdomain call. Is that correct? %define parse.error detailed %{ #define YYENABLE_NLS 1 #define ENABLE_NLS 1 #define N_ static auto _ (const char *s) { return dgettext ("mydomain", s); } %} Regards, Frank
