Re: Get allowed-next-tokens in yacc?

Maurizio Vitale <vitale@esat.kuleuven.ac.be>
6 Mar 1998 16:53:43 -0500

          From comp.compilers

Related articles
Get allowed-next-tokens in yacc? rfaulds@avici.com (R Faulds) (1998-03-03)
Re: Get allowed-next-tokens in yacc? vitale@esat.kuleuven.ac.be (Maurizio Vitale) (1998-03-06)
Re: Get allowed-next-tokens in yacc? vladimir@cs.ualberta.ca (Vladimir Alexiev) (1998-03-07)
| List of all articles for this month |

From: Maurizio Vitale <vitale@esat.kuleuven.ac.be>
Newsgroups: comp.compilers
Date: 6 Mar 1998 16:53:43 -0500
Organization: katholieke Universiteit, Leuven
References: 98-03-005
Keywords: parse, yacc

"R Faulds" <rfaulds@avici.com> writes:
> 1) Is there a way (without hacking y.tab.c) to get the list of allowed
> tokens for some (any) point in the parse process?


Yes, I did it too many years ago for remembering the details, but you
should be able to recover the method from studying the Dragon book and
the parser skeleton (which ultimately make up part of y.tab.c). It
was basically an enumeration of all possible token types followed by a
lookup in the yacc generated tables for possible transitions to a
final state.


If you were looking for a way for doing it without writing additional
code, I believe the answer is no: the information you're looking for
is only implicitely stored in the generated tables. Of course YACC and
bison have exactly the information you want and could be hacked to
generate additional tables if needed.


> [Honestly, I wouldn't use yacc. Getting the actual list of allowed tokens
> at each point is really hard due to the state and table compaction that
> yacc does. And the error recovery is no prize-winner. -John]


Well, I have to disagree: I remember it was one day of work for
demonstrating the feasibility of it to my boss and some more time to
get the details exactly right (as usual that part takes longer...)


I second the suggestion of not using YACC for this particular
application, because the grammar for a command line interface is
likely to be easy enough for an hand-coded recursive descent parser.
This gives you more context for good error recovery.


Maurizio
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.