Re: The Location handling

[Paul Eggert]

Akim Demaille <address@hidden> writes:

> I meant to introduce an additional directive, something like
> 
> %initial-location { SOME-VALUE }
> ...
> |   /* The variables used to return semantic value and location from the
> |      action routines.  */
> |   YYSTYPE yyval;
> | ]b4_location_if([  YYLTYPE yyloc[]b4_default([= b4_location_initial]);])[
>  
> This scheme preserves the advantage that the user can use a
> dynamically computed value, based on %parse-param.

In Bison itself, it's not necessary to initialize the entire location;
one needs to initialize only part of yyloc.  This suggests that the
initialization need not be done via a C initializer; it might be
some arbitrary bit of C code instead, executed for side effect.

Admittedly this is a minor point in the case of Bison, as we don't
care about the loss of efficiency.  Still, it is a bit worrisome that,
in the very first use of this proposed feature, the feature is
overkill and causes us to generate code that we don't need.

Another possible reason that an initializer would be unworkable is if
we want to assume C89, and yyloc is a struct, and b4_location_initial
is an initializer that contains some non-constant expressions.  This
combination is not allowed in C89; you have to break the
initialization out into a series of assignments instead.

All this argues for the %initial-action syntax that you suggest below.

> even in the case someday someone wants to introduce a skeleton that
> does not support this yyloc persistence, it would be a simple
> matter, imo, to add another variable to make it persistent.

That sounds plausible to me, though I think it could well make things
less efficient to implement persistence.

> And finally, when I think about the scanner/parser with Bison, I keep
> in mind a reentrant usage, in which case, even if we use the
> scanner_cursor technique, its initial value must be passed by yyparse
> to yylex.

I think that's OK.  In general, one must initialize a reentrant lexer
by giving it whatever information is necessary to do lexical analysis.

> another means to fix bison would be to introduce something like
> 
> %initial-action {
>   @$ = WHAT-EVER;
>   lfprintf (stderr, @$, "Hello world\n");
>   @$.last_line = -42;
> }
> 
> and it would be cumulative, i.e., except for the empty line, the
> paragraph above would be the same as
> 
> %initial-action { @$ = WHAT-EVER; }
> %initial-action { lfprintf (stderr, @$, "Hello world\n"); }
> %initial-action { @$.last_line = -42; }
> 
> I'm OK with experiencing this scheme, but, as with %initial-location,
> I vote for a solution used by Bison for Bison, and not published in
> any way (err, except the code :).

I like this idea better, for the reasons mentioned above.  And once we
have %initial-action, we don't need %initial-location.

I assume the initial actions would be inserted just before the "goto
yysetstate;" in data/yacc.c.