|Lazy/tolerant parsers firstname.lastname@example.org (2004-07-13)|
|Re: Lazy/tolerant parsers email@example.com (Dmitry A. Kazakov) (2004-07-14)|
|Re: Lazy/tolerant parsers firstname.lastname@example.org (2004-07-15)|
|Re: Lazy/tolerant parsers email@example.com (Dmitry A. Kazakov) (2004-07-17)|
|From:||"Dmitry A. Kazakov" <firstname.lastname@example.org>|
|Date:||17 Jul 2004 18:06:35 -0400|
|References:||04-07-029 04-07-039 04-07-046|
|Posted-Date:||17 Jul 2004 18:06:35 EDT|
On 15 Jul 2004 16:35:08 -0400, Akhilesh Mritunjai wrote:
> "Dmitry A. Kazakov" <email@example.com> wrote
>> Ada 95 expression parser and tree generator). The parser stops at
>> something it cannot recognize. At this point one can determine its
>> state. I.e. how many unclosed brackets, missing right operands etc you
>> have. One can use some kind of pattern matching to jump over an
>> indigestible part (not a name or literal, but just rubbish) and
> To where ?? That was the second part to my question.
To the next delimiter would be my first guess.
> From my parser I can get details of how and where the error
> happened. But still the questions of how to
> - recover from the error
Ideally there should be no other errors than "I do not understand the next
token". So you skip it and continue.
> - resynch
If you know the parser state, then you can take advantage of it. For
example, semicolon can close all open left brackets, always. "end;" should
close all "if", "case", "begin" etc.
> - continue parsing as if unaffected from error
> are open. Can't seem to find out a good solution to these problems.
Dmitry A. Kazakov
Return to the
Search the comp.compilers archives again.