[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Should YYLTYPE represent the location or the position,
Akim Demaille <=