RE: location tracking in glr-parsers

[Virgil Nicula]

Hans-

Many thanks, now I understand that I am not the only one concerned about
unused YYLLOC_DEFAULT macro (when %glr-parser and %pure-parser are used).

I hope locations tracking support will find a place in the development
process. There are many old applications that use it and their
maintainers/developers cannot switch to a powerful parsing mode like GLR
because of this lack of locations support. Usually the grammar is very
large, has hundreds of conflicts and nobody wants to reduce it to a LALR(1)
form. But everybody wants to add new grammar rules so all we want is a
better parser:) but you already know this. And about "what good locations
tracking should consist of", you have made a good point. If all bison users
would agree that we want the good old simple 4 int structure ported to GLR
parsers, who will oppose to that?

best regards,
gill

P.S.
Hoping that it may be useful for someone sometime, here is the way I managed
to solve this (by reinventing the wheel of course):

1)      I redefined a similar structure in a separate header file with some
macros:

// Location handling
struct ParserLocation
{
  int first_line;
  int first_column;
  int last_line;
  int last_column;
};

/* Initialize*/
#define LOCATION_RESET(Loc)                  \
  (Loc)->first_column = (Loc)->first_line = 1; \
  (Loc)->last_column =  (Loc)->last_line = 1;

/* Advance of NUM lines. */
#define LOCATION_LINES(Loc, Num)             \
  (Loc)->last_column = 1;                     \
  (Loc)->last_line += Num;

/* Restart: move the first cursor to the last position. */
#define LOCATION_STEP(Loc)                   \
  (Loc)->first_column = (Loc)->last_column;    \
  (Loc)->first_line = (Loc)->last_line;

2)      I have put the dirty work in lexer:

#define YY_USER_ACTION  yylloc->last_column += user_leng;
#define YY_USER_INIT LOCATION_RESET(yylloc)

and appropriate actions for newline's:

{BLANK}+ {
  /* Eat whitespace */
  LOCATION_STEP(yylloc);
}

\n {
  LOCATION_LINES(yylloc, 1);
  LOCATION_STEP(yylloc);
}

";".* {
  /* End-line comment                     */
  /* Eat everything up to the end of line */
  /* but not including the '\n' character */
  LOCATION_STEP(yylloc);
}
etc etc

LOCATION_STEP is invoked in every lexer action to put the correct values in
the location structure for the parser.

3)      I made the connections between prototypes:
In flex file:

#define YY_DECL \
  int yylex(YYSTYPE* yylval, ParserLocation* yylloc, UserContext* yycontrol)

In Bison file:

#define YYLTYPE ParserLocation
int user_lex(YYSTYPE*, ParserLocation*, UserContext*);

4)      And it is working because with options %pure-parser and %glr-parser the
lexer is invoked in yyparse like:

#define YYLEX yylex (yylvalp, yyllocp, user_control) //where yyllocp is
YYLTYPE* const yyllocp = &yylloc; //from yyparse()

And yylloc is defined as:

YYLTYPE yylloc; //from yyparse()

end.

-----Original Message-----
From: Hans Aberg [mailto:address@hidden
Sent: Tuesday, March 16, 2004 10:13 AM
To: Virgil Nicula
Cc: address@hidden
Subject: Re: location tracking in glr-parsers


At 17:21 -0800 2004/03/15, Virgil Nicula wrote:
>How can someone use the location tracking in combination with:
>
>%pure-parser
>%glr-parser

You might have look in the Bug-Bison archive, thread "GLR parsers and
locations", first post 5 Jun 2003.

The long and short story of the Bison locations tracking, is that derives
from original Bison written by Corbett for his thesis work, but it was left
unsupported for many years, in due part because one has not agreed on what
good locations tracking should consist of. So it may be the case nobody has
implemented a good generic location tracking feature yet.

  Hans Aberg