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

[Peter Jay Salzman]

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.

> 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.  so the start of my parser now looks like:

   %{
   #include <stdio.h>
   #include <stdlib.h>
   #include "hdr/MyParse.h"
   #include "hdr/global.h"
   #include "hdr/routines.h"
   extern int yylex();
   
   void yyerror(const char *string)
   {
   	pushWin3("Error: %s.", string);
   }
   
   %}
   (snip)

bison provides a default yyerror, which prints to stdout.  since this is
an ncurses program, i believe "parse error" was being printed out -- i
just wasn't seeing it.  so i replaced yyerror with my own homebrewed
error routine which eventually prints the error to an ncurses *WINDOW.

there's still a fly in the ointment.  apparently, even a parse error
will push an unrecognized input back onto the stack three times before
yacc gives up.  this explains why the parser would "get wierd" for a
short while after a grammar error, but would eventually fix itself.

there are some things that sound like they can help here --
YYABORT, YYACCEPT, YYERROR yyclearin and yyerrok.  i need to do some
reading about what exactly they do and how they're used.  as a wild shot
in the dark, i stuck them one by one in my homebrewed yyerror() but gcc
didn't recognize them.  supposedly they're macros.

it's possible that it's a bison/yacc incompatibility, but i was under
the impression that bison is nearly 100% yacc compatible.

anyway, i guess it now boils down to rtfm (or being spoonfed if anyone
here knows about this stuff).

> I say "I think" because I haven't built an interactive parser before.

heh.  is that seat next to you taken?   :)

pete

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