Re: few questions

[Hans Aberg]

At 11:47 -0700 2004/07/27, Aleksey Perfilov wrote:
>Hi, guys.   I need help with improving my syntax error messages.   Right
>now I just have standard bison error handling where it looks at  possible
>tokens and    says <token> expected.   Few quetions, if you don't have
>time to read all, please answer just on one  or two of them.  
>question 1:   I am not exactly clear on contents of yytable, what does it
>mean "portions  for different    uses" ? What do those portions contain
>and in what format?

The best way figure that out is to read the parser code, and see how it is
used. There is no documentation, and people general do not have time to go
in and figure that for you.

question 2:   if I put an error token in a rule that doesn't have a closing
token like  this   stmnts:  /* empty string  */
>        | stmnts  '\n'
>        | stmnts exp  '\n'
>        | error   is error token going to match all of the remaining
>output if syntax error  occurs?

Read the Bison manual on how error recovery works. Roughly, it pops the
parser stack, until it finds an error recover symbol, and tries to continue
there on. The best way is to experiment with that in practise: When an
error token is found, LALR(1) relative LR(1) may add a few more actions
before an error is initiated. So you can't be too sure to get the effects
you want.
 
>question 2:   what if I have a mid rule where I decide that something's
>wrong and want to  ignore the whole    expression   expr : part1 { some
>checks here } part2 part3 part4 part5   How can I go about it?

The midrule actions are implemented by adding a new, anonymous, grammar
variable with empty expansion and the indicated midrule action. So the
effects will always be same as of that implementation.

>question 3:   If I get an error in lexer, for example closing comment w/o
>opening  comment, how can I get    the parser to ignore the token or maybe
>a serie of tokens?

Only by making sure that no error tokens are fed to the parser.

>question 4:   In Bison code there is YYFAIL macro that goes to yyerrlab:
>Is it the  default action when an error is encountered?

The parser code says:
#define YYERROR         goto yyerrlab1
/* Like YYERROR except do call yyerror.  This remains here temporarily
   to ease the transition to the new meaning of YYERROR, for GCC.
   Once GCC version 2 has supplanted version 1, this can go.  */
#define YYFAIL          goto yyerrlab

So when YYERROR is used, the error reporting must be done explicitly:
        yyerror("...");
        YYERROR;
YYFAIL uses the Bison default error reporting mechanism.
  
>question 5:   For example if I have a piece of program like this:   a=1
>b=2;   when parser reads "b" it errors, I print "missing semicolon" but
>then I  want to continue    parsing. How do I put back "b" so that b=2; is
>parsed successfully.  

Good error recovery is a research topic. So I think are more likely
approach is to report the error, and skip forward to a point where easy
error recovery can be made.

  Hans Aberg