parser error recovery

I'm writing an LL parser for a C like language and I've run into a bit of confusion on the logic of implementing an error recovery scheme. I will be using panic mode, just skip tokens until I find one of Follow(A) or EOF, but I'm not sure if I need to crawl out of my deep stack of function calls, or since I am finding a Follow in the rule I'm currently parsing if I even need to get out. (sorry for the poorly phrased sentence)

Thanks.

Quote:

---

but I'm not sure if I need to crawl out of my deep stack of function calls

---

It's not that difficult to do this.

We'll probably need to see your code to help you some more.

It may be easier if I just give you a chunk of my grammar, the code is somewhat long.
Just say if you still need some of the code. (E is empty in the below grammar)

Code:

---

expression = id '=' expression | condition
condition = and ('||' and)*
and = equal ('&&' equal)*
equal = relation ('==' relation | E)
relation = sum (('>' | '<') sum | E)
sum = term (('+' | '-') term)*
term = unary (('*' | '/' | '%') unary)*
unary = atom | ('!' | '-') unary
atom = int | float | id | '(' expression ')'

---

So if I'm parsing:
q = i+j*+k
I see the * and call unary, I get down to atom and see I have none of int, float, id, '(' so I error, but then do I just eat tokens till I get one of Follow(atom) and the problem is solved?

You could do that, but I would unwind the stack and prompt for another expression.

It's not just a simple prompt, it's a small C like language compiler that takes a file to compile as an argument so unfortunately I can't just return the first error I find, I have to try to recover and find more errors.

Oh, I see. In that case I would keep going.

I started the code and it's failing, I imagine it's due to my incorrect understanding and/or logic.

Given something like this:

Code:

---

program = var_type id(var_type id)
var_type = int | float | char

---

and an input file like this

Code:

---

main(float x)

---

The rule program will fail because it first expects to see a var_type but instead sees an id. id is in follow var_type so do I eat no tokens? Or do I eat the erroneous token before I start looking for a new token in Follow?

Thanks again.

recovering is a 'nice' feature but hardly required. the overhead and logic might even introduce bugs in the parser if implemented incorrectly. one way is to join the rules (using binary OR) with an 'expected' rule that sets the parser in the correct state (by eating tokens or whatever) to continue parsing as you build up error messages. something along the lines of:

some_rule = (var_type | expected(var_type)) (id | expected(id)) /* etc */

whether that method would work for you or not depends on how the parser is implemented. at any rate it's a pretty top-heavy approach! there are probably better ways of course, you might browse the code to an existing compiler or try google on other approaches to your problem.

Since it's a project for school I sadly am forced to implement it.
The project specifications only states we use the Follow sets as 'anchor' tokens, however, this works terribly so I added the First sets as well which improved it a bit. I'll go ahead and try to implement what you have suggested as well.

Thank you very much for your input.