Re: FYI: Adjust @$ for empty reductions

[Akim Demaille]

>>> "Paul" == Paul Eggert <address@hidden> writes:

 > Akim Demaille <address@hidden> writes:
 >> The distance between the boundaries of the token returned by yylex
 >> is yyleng (except when there are newlines of course).

 > Tabs are another exception.

 > Another exception can occur with multibyte characters.  In UTF-8 it is
 > common for the number of bytes to not equal the number of columns.
 > For example, the UTF-8 representation for most Japanese characters
 > consumes 3 bytes, but these characters typically consume only 2
 > columns.

Agreed, I was not considering the special cases.

 > The Bison manual should probably mention all this somewhere, sigh.

I think we should first continue to gain experience on that matter,
and then do it.

 >> I don't see that here.  This code does not make the provision that
 >> location_print did, that's all.

 > Sorry, I don't follow.  Are you saying the code is buggy?  Or that it
 > generates consistent but weird output?

It produces a different output, that's all.  I'm not saying it's
buggy, but I wouldn't use it.

 > As an aside, it would be clearer if the examples were changed to
 > follow the GNU coding standards for column numbers in error messages:
 > currently they output stray "l"s and "c"s.

Sure.  A complete pass on the documentation of locations is to be
done, once everything settled down.


 >> I do not agree with the ending boudary issue: it is a non issue.
 >> They have been implemented differently.  Sometimes they have been
 >> presented differently, period.

 > OK, I'm starting to see it now.  (I'm looking forward to an
 > entertaining reading in NEWS.  :-)

:)



While I think we agree on the _implementation_ of locations (including
the representation of empty locations with equal boundaries), you do
have a point wrt the printing of locations.  Especially because,
eventually, tools (such as Emacs' compile-mode) should be able to
highlight the part of the sources corresponding to the displayed
location.  So we should complete the GCS with a better description of
the meaning of these locations.

Printing them as they are is the simplest, and safest.  Printing them
in terms of characters is much more natural IMO, but it relies on a
trick: backing up from one character, as in location_print:

  if (loc.start.file != loc.end.file)
    fprintf (out, "-%s:%d.%d",
             quotearg_n_style (3, escape_quoting_style, loc.end.file),
             loc.end.line, loc.end.column - 1);
  else if (loc.start.line < loc.end.line)
    fprintf (out, "-%d.%d", loc.end.line, loc.end.column - 1);
  else if (loc.start.column < loc.end.column - 1)
    fprintf (out, "-%d", loc.end.column - 1);

which gives of course weird results in the case where the last column
was 0.  I tend to think that such case are only theoretical and won't
appear in practice.  We sure can invent an artificial grammar
exhibiting such a "need", but I don't believe it will happen
naturally.  Hence I'm in favor of keeping the location reports the way
we do: with inclusive boundaries.