[vox-tech] how to get yacc/bison to say "i'm confused" (solved)

[Peter Jay Salzman]

brilliant, as always.

i think i have a fully operational program on my hands....   :-)

well, actually, i never got the program to print the screen, but i think
i've pretty much given up on printing.  :-(

other than that, everything works just swimingly.  and now i can say
that i more or less know how to use lex/yacc.

thanks, jeff!  you definitely saved the day.

pete


begin Jeff Newmiller <jdnewmil@dcn.davis.ca.us> 
> On Thu, 27 Dec 2001, Peter Jay Salzman wrote:
> 
> > begin Jeff Newmiller <jdnewmil@dcn.davis.ca.us> 
> > > On Thu, 27 Dec 2001, Peter Jay Salzman wrote:
> > > 
> > > > newbie here.
> > > > 
> > > > i'm using flex/bison for processing a program's user input, and have a
> > > > list of rules that define the user input grammar.
> > > > 
> > > > after bison processes all it's input, is there a way of telling it:
> > > > 
> > > >    if no rule matched the input, take your input and feed it to
> > > >    ParseError(const char *error)?
> > > > 
> > > > the problem i'm having is typically:
> > > > 
> > > > 	ruleset:    TOK_RULESET NUMBER    { ChangeRuleset($2); }
> > > > 		|        TOK_RULESET           { ChangeRuleset(-1); }
> > > > 
> > > > if the user types something like "ruleset asdf", it'll match
> > > > "TOK_RULESET", and (i think) "asdf" gets put back into the buffer since
> > > > it's not a NUMBER, and is processed the next time the user inputs
> > > > something.  in other words, bison gets out of sync and confused.
> > > 
> > > I think your rules do not convey that you feel the "asdf" must be
> > > associated with "ruleset" even though it isn't a number.  Your definition
> > > of "ruleset" says a bare "ruleset" token can be a valid ruleset, so
> > > any non-number following it must be associated with another rule.
> >  
> >  i see what you mean, but i think bison knows the end of input since my
> >  input is coming from a const char * (as opposed to a file) and i used
> >  lex to define \n to return 0.  i believe bison recognizes 0 to mean end
> >  of input.
> 
> Yes, bison recognizes 0 as end of input.  I am not talking about end of
> input... I am talking about defining what a whole "ruleset" command is.
> 
>  	ruleset:    TOK_RULESET NUMBER EOC  { ChangeRuleset($2); }
>        |        TOK_RULESET EOC         { ChangeRuleset(-1); }
> 
> where your lexical parser would identify the end of command as newline,
> unexpected end of string (have it insert an EOC before returning the 0),
> semicolon, or what have you.
> 
> > > I think you need to specify a terminal "end of arguments" token in your
> > > syntax to identify "optional argument" behavior.  This could be
> > > end-of-line, or semicolon, or parentheses.  Then, the "ruleset" rule
> > > cannot match "ruleset asdf" because the end-of-arguments token will follow
> > > the unrecognized "asdf".
> > 
> > i managed to stumble across the fact that you can redefine yyerror(),
> > which does exactly what i want it to.  if bison can't parse an input
> > correctly, it calls yyerror.
> 
> But without the end of command token, the "asdf" appears to stand on its
> own as a command instead of as an invalid argument to the "ruleset"
> command.  The difference lies in the clarity of error reporting.

-- 
PGP Fingerprint: B9F1 6CF3 47C4 7CD8 D33E  70A9 A3B9 1945 67EA 951D
PGP Public Key:  finger p@dirac.org