Re: [Bison-Announce] Bison 3.5.90 released [beta]

[Frank Heckenbach]

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