The Location handling

[Akim Demaille]

Hi Paul,

I believe we should focus on releasing a Bison in the near future, and
therefore I'll hold my concerns for a while.  But that is just
delaying them :)

In any case, we must make a final decision wrt the handling of
locations.  I believe that Bison should continue exploring the area,
and once we are totally satisfied, we can write the documentation and
code for others to support locations properly.

My main concern is that up to today, there is no clear agreement
between you and me wrt how to initialize the very first location, and
actually, even how to track them.

You explained that the main raison d'être of scanner_cursor is to
respect the usual information flow between the scanner and the parser:
up to now, the scanner expects nothing from the parser.  My proposal,
which consists in letting the parser be the keeper of the current
location, breaks this scheme.  In addition, as you pointed out,, it
requires that *all* the parsers, including the non deterministic ones,
must guarantee that the latest location received by the parser be
transmitted to the scanner in the following call.

All this tends to demonstrate that your approach is the right one.

Unfortunately...

Unfortunately, this does not cope well with initial empty reductions
(spontaneous :), i.e., reductions that Bison parser are allowed to
make before even calling yylex [1].  That is the reason why I meant to
introduce an additional directive, something like

%initial-location { SOME-VALUE }

which will result in something like:

|   /* The variables used to return semantic value and location from the
|      action routines.  */
|   YYSTYPE yyval;
| ]b4_location_if([  YYLTYPE yyloc;])[
 
becoming

|   /* 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.


About your concern wrt preserving yyloc.  I believe this commitment is
not too strong, and anyway it turns out that calc.at is implemented
the location tracking a` la Akim (i.e., using yyloc only), not a` la
Paul (with scanner_cursor).  The results are correct.  Admittedly,
calc does not exercise actual nondeterminism.  But 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.  So I can't imagine a
situation where we would consider this persistence an error.

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.  It results in an additional traffic between yylex and
yyparse if it is not done by yyloc.



To conclude, I believe the only means to continue with the fine
grained scheme we have in Bison currently, we need something like
%initial-location (or %location-initial?).  I think we should
implement its support in Bison but not document it, so that we
continue exploring Bison with Bison, and then, once satisfied,
"release" the feature in the next release.

What is your opinion?


Oh, BTW, there is one feature granted by Flex, and not by Bison: code
to executed before the execution of the parsing per se.  This feature
could be used to initialize the initial location, and additionally,
being more generic, it would also solve other problems.  But in this
case, it would require exhibiting yyloc in the parser, which would be
novel and certainly wrong.  That is the purpose of %initial-location:
a more abstract interface.

Nevertheless, we could support @$ in this.  So, 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 :).

Amicalement,  (I really don't know how to make this guy English)

        Akim




[1] The test suite does not exercise this case.  But bison's grammar
does.  As of today, Bison does use uninitialized values.