36 ms·

I guess the major downside of this approach is that your state is spread through a call stack rather than in a parse stack sitting in an array and a pointer som

I guess the major downside of this approach is that your state is spread through a call stack rather than in a parse stack sitting in an array and a pointer somewhere. That makes error recovery really really difficult, because you have to unwind the call stack to the next recovery state rather just messing with the contents of the array and pointer. I can understand the teaching value in doing it this way but students really need to understand the value of table driven tools in the real world

Taniwha 4y ago
I'll add few people use the trick of extending LR grammars by resolving conflicts dynamically on the fly (you can do stuff like implementing languages that allow change of operator precedence) - because the usual tools don't support this well it's probably easier to implement in this top-down methodology
- Joker_vD 4y ago
  Here's an example of doing this in a top-down parser, by Bob Nystrom (author of "Crafting Interpreters"): [0]. [0] http://journal.stuffwithstuff.com/2011/02/13/extending-syntax-from-within-a-language/ http://journal.stuffwithstuff.com/2011/02/13/extending-synta...
Joker_vD 4y ago
In my experience, it doesn't make error recovery difficult, not really, even without exception throwing. Then again, I mostly stick to the panic-mode recovery: on unexpected input, record an error in a global list of errors, skip tokens until end of phrase, return a bogus node. Depending on what exactly "bogus" means, you end with error-productions or just completely made up but otherwise perfectly valid nodes somewhere deep inside your parse/abstract tree which is why recording presence of errors somewhere off-side is a good idea. I imagine a slighlty more elaborate error recovery approach could return different kinds of bogus nodes and check for them and process them differently in different productions.

Taniwha 4y ago

I'll add few people use the trick of extending LR grammars by resolving conflicts dynamically on the fly (you can do stuff like implementing languages that allow change of operator precedence) - because the usual tools don't support this well it's probably easier to implement in this top-down methodology

Joker_vD 4y ago
Here's an example of doing this in a top-down parser, by Bob Nystrom (author of "Crafting Interpreters"): [0]. [0] http://journal.stuffwithstuff.com/2011/02/13/extending-syntax-from-within-a-language/ http://journal.stuffwithstuff.com/2011/02/13/extending-synta...

Joker_vD 4y ago

In my experience, it doesn't make error recovery difficult, not really, even without exception throwing. Then again, I mostly stick to the panic-mode recovery: on unexpected input, record an error in a global list of errors, skip tokens until end of phrase, return a bogus node. Depending on what exactly "bogus" means, you end with error-productions or just completely made up but otherwise perfectly valid nodes somewhere deep inside your parse/abstract tree which is why recording presence of errors somewhere off-side is a good idea. I imagine a slighlty more elaborate error recovery approach could return different kinds of bogus nodes and check for them and process them differently in different productions.