[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FYI: lalr1.cc: too far on the left
From: |
Akim Demaille |
Subject: |
Re: FYI: lalr1.cc: too far on the left |
Date: |
Fri, 21 Feb 2003 09:07:16 +0100 |
User-agent: |
Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2 |
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