Re: FYI: lalr1.cc: too far on the left

[Akim Demaille]

 Paul> Akim Demaille <address@hidden> writes:
 >> Paul, I saw you were using Boundary where I use Position.  I kept
 >> Position for historical reason (used this name for years now), but if
 >> in English Boundary is better, I'm fine with this.

 Paul> I think I used "boundary" in bison/src/location.h and its
 Paul> clients because the Bison manual uses the word "position" to
 Paul> mean location, e.g., it has a @node "Token Positions" that uses
 Paul> the terms "position" and "location" interchangeably.  These
 Paul> terms both cover the entire range of a terminal or nonterminal,
 Paul> from beginning to end.  To avoid confusion with the manual, I
 Paul> used a different word.

Ah, good point, thanks!

 Paul> Sorry, I didn't realize that "position" was used in the "boundary"
 Paul> sense in data/lalr1.cc.

 Paul> Either word is fine with me, so long as the documentation and
 Paul> code use it consistently.

I'm applying the following.

Index: ChangeLog
from  +2003-02-21  Akim Demaille  <address@hidden>

        * doc/bison.texinfo: Use "location" consistently to refer to @n,
        to avoid confusions with lalr1.cc's notion of Position.
        Suggested by Paul Eggert.

Index: doc/bison.texinfo
===================================================================
RCS file: /cvsroot/bison/bison/doc/bison.texinfo,v
retrieving revision 1.100
diff -u -u -r1.100 bison.texinfo
--- doc/bison.texinfo 13 Jan 2003 06:41:29 -0000 1.100
+++ doc/bison.texinfo 21 Feb 2003 08:04:05 -0000
@@ -237,7 +237,7 @@
 * Calling Convention::  How @code{yyparse} calls @code{yylex}.
 * Token Values::      How @code{yylex} must return the semantic value
                         of the token it has read.
-* Token Positions::   How @code{yylex} must return the text position
+* Token Locations::   How @code{yylex} must return the text location
                         (line number, etc.) of the token, if the
                         actions want that.
 * Pure Calling::      How the calling convention differs
@@ -855,12 +855,12 @@
 @node Locations Overview
 @section Locations
 @cindex location
address@hidden textual position
address@hidden position, textual
address@hidden textual location
address@hidden location, textual
 
 Many applications, like interpreters or compilers, have to produce verbose
 and useful error messages.  To achieve this, one must be able to keep track of
-the @dfn{textual position}, or @dfn{location}, of each syntactic construct.
+the @dfn{textual location}, or @dfn{location}, of each syntactic construct.
 Bison provides a mechanism for handling these locations.
 
 Each token has a semantic value.  In a similar fashion, each token has an
@@ -3071,8 +3071,8 @@
 @node Locations
 @section Tracking Locations
 @cindex location
address@hidden textual position
address@hidden position, textual
address@hidden textual location
address@hidden location, textual
 
 Though grammar rules and semantic actions are enough to write a fully
 functional parser, it can be useful to process some additional information,
@@ -3971,7 +3971,7 @@
 * Calling Convention::  How @code{yyparse} calls @code{yylex}.
 * Token Values::      How @code{yylex} must return the semantic value
                         of the token it has read.
-* Token Positions::   How @code{yylex} must return the text position
+* Token Locations::   How @code{yylex} must return the text location
                         (line number, etc.) of the token, if the
                         actions want that.
 * Pure Calling::      How the calling convention differs
@@ -4104,8 +4104,8 @@
 @end group
 @end example
 
address@hidden Token Positions
address@hidden Textual Positions of Tokens
address@hidden Token Locations
address@hidden Textual Locations of Tokens
 
 @vindex yylloc
 If you are using the @samp{@@@var{n}}-feature (@pxref{Locations, ,
@@ -4148,7 +4148,7 @@
 @end example
 
 If the grammar file does not use the @samp{@@} constructs to refer to
-textual positions, then the type @code{YYLTYPE} will not be defined.  In
+textual locations, then the type @code{YYLTYPE} will not be defined.  In
 this case, omit the second argument; @code{yylex} will be called with
 only one argument.
 
@@ -4410,7 +4410,7 @@
 
 @deffn {Value} @@$
 @findex @@$
-Acts like a structure variable containing information on the textual position
+Acts like a structure variable containing information on the textual location
 of the grouping made by the current rule.  @xref{Locations, ,
 Tracking Locations}.
 
@@ -4436,7 +4436,7 @@
 
 @deffn {Value} @@@var{n}
 @findex @@@var{n}
-Acts like a structure variable containing information on the textual position
+Acts like a structure variable containing information on the textual location
 of the @var{n}th component of the current rule.  @xref{Locations, ,
 Tracking Locations}.
 @end deffn
@@ -6562,8 +6562,8 @@
 numbers associated with a token.  (In a pure parser, it is a local
 variable within @code{yyparse}, and its address is passed to
 @code{yylex}.)  You can ignore this variable if you don't use the
address@hidden@@} feature in the grammar actions.  @xref{Token Positions,
-,Textual Positions of Tokens}.
address@hidden@@} feature in the grammar actions.  @xref{Token Locations,
+,Textual Locations of Tokens}.
 @end deffn
 
 @deffn {Variable} yynerrs