Post by email@example.com
sticking point in my first cut compiler which was purely recursive descent
is that error recovery is very hard to do in recursive descent, and a huge
amount of extra code exists to exit out of deeply nested function calls.
This was always a weak spot in the Wirth code examples which i learned
How old were these examples that you were using? The strategy used by Wirth in his latest Project Oberon compiler does not have that problem. He describes the strategy as follows:
"Also, the language Oberon is designed with the property that most large constructs begin with a unique symbol, such as IF, WHILE, CASE, RECORD, etc. These symbols facilitate the recovery of the parsing process in the erroneous text. More problematic are open constructs which neither begin nor end with key symbols, such as types, factors, and expressions. Relying on heuristics, the source text is skipped up to the first occurrence of a symbol which may begin a construct that follows the one being parsed. The employed scheme may not be the best possible, but it yields quite acceptable results and keeps the amount of program devoted to the handling of erroneous texts within justifiable bounds."
For the full source code of including extensive documentation of his RISC5 Oberon compiler and the operating system that was built entirely using the language see 'Project Oberon 2013' at:
If your compiler is having difficulty parsing your language then you should consider that as a warning sign that humans may have similar difficulties when trying to fully comprehend your language. I'd advise you to rethink the language design for areas that are causing you specific problems.