help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should YYLTYPE represent the location or the position


From: Akim Demaille
Subject: Re: Should YYLTYPE represent the location or the position
Date: Sun, 3 May 2020 10:51:54 +0200

Hi Arthur,

> Le 14 déc. 2013 à 00:47, Arthur Schwarz <address@hidden> a écrit :
> 
> The manual doesn't make clear whether YYLTYPE should represent the 
> location_type or the position_type. It is inferred that YYLTYPE refers to the 
> position_type, because the position of atoken should be returned by the 
> scanner. The terminology and macros seem to indicate a location rather than a 
> position. I wonder if in future versions of the manual it can be made clear 
> that there is a distinction between the position_type and the location_type, 
> and that the location_type is a calculated quantity within the parser and 
> that location_type is used exclusively with the scanner. And in the same 
> light, maybe change the terminology to reflect this understanding, such as 
> using plocp instead of llocp, et alia. The alternative is to change the 
> classes, structures, and manual so that location means position and position 
> means location. As it stands now, oftentimes location seems to mean position.
> 
> This all leads up to the question of "who's on first". The flex manual always 
> uses location to refer to position, and in consequence, all terminology and 
> names reflect location. This terminology is carried over into Bison but here, 
> location means position. The manual should at least describe what is going on 
> if not make the terminology, classes, and macros consistent.

As far as Bison is concerned, YYLTYPE is definitely a location.  Of course the 
really question is what is a /location/.

Bison just doesn't care.  It can be a range, a point, a collection of ranges, 
etc, we just don't care.

The *default* definition in C is four integers (start/end line/column).  In C++ 
it is two "Positions", etc.

I'm installing this.

Thanks!


commit c0bc74ddfdf791b32f66443948add41294623136
Author: Akim Demaille <address@hidden>
Date:   Sun May 3 10:46:59 2020 +0200

    doc: clarify what a location is
    
    Reported by Arthur Schwarz <address@hidden>
    https://lists.gnu.org/r/help-bison/2013-12/msg00009.html
    
    * doc/bison.texi (Location Type): here.

diff --git a/THANKS b/THANKS
index 805c744f..48b31ea9 100644
--- a/THANKS
+++ b/THANKS
@@ -20,6 +20,7 @@ Anthony Heading           address@hidden
 Antonio Silva Correia     address@hidden
 Arnold Robbins            address@hidden
 Art Haas                  address@hidden
+Arthur Schwarz            address@hidden
 Askar Safin               address@hidden
 Balázs Scheidler          address@hidden
 Baron Schwartz            address@hidden
diff --git a/doc/bison.texi b/doc/bison.texi
index fe3f6d0f..60cf5dba 100644
--- a/doc/bison.texi
+++ b/doc/bison.texi
@@ -4505,12 +4505,18 @@ typedef struct YYLTYPE
 @} YYLTYPE;
 @end example
 
+While default locations represent a range in the source file(s), this is not
+a requirement.  It could be a single point or just a line number, or even
+more complex structures.
+
 When @code{YYLTYPE} is not defined, at the beginning of the parsing, Bison
 initializes all these fields to 1 for @code{yylloc}.  To initialize
 @code{yylloc} with a custom location type (or to chose a different
 initialization), use the @code{%initial-action} directive.  @xref{Initial
 Action Decl}.
 
+
 @node Actions and Locations
 @subsection Actions and Locations
 @cindex location actions
@@ -14736,8 +14742,8 @@ In semantic actions, it stores the location of the 
lookahead token.
 @end deffn
 
 @deffn {Type} YYLTYPE
-Data type of @code{yylloc}; by default, a structure with four members.
-@xref{Location Type}.
+Data type of @code{yylloc}.  By default in C, a structure with four members
+(start/end line/column).  @xref{Location Type}.
 @end deffn
 
 @deffn {Variable} yylval




reply via email to

[Prev in Thread] Current Thread [Next in Thread]