Happy catchtok #283
Happy catchtok #283
Conversation
Kariiem
force-pushed
the
happy-catchtok
branch
2 times, most recently
from
474bcfd to
1a27312
Compare
Kariiem
force-pushed
the
happy-catchtok
branch
3 times, most recently
from
8f45e4d to
179bdfd
Compare
| -- 2. Error resumption mode: If the error handler wants to resume parsing in | ||
| -- order to report multiple parse errors, it will call the resumption | ||
| -- continuation (of result type `P (Maybe a)`). | ||
| -- In the absence of the %resumptive declaration, this resumption will | ||
| -- always (do a bit of work, and) `return Nothing`. | ||
| -- In the presence of the %resumptive declaration, the grammar author | ||
| -- can use the special `catch` terminal to declare where parsing should | ||
| -- resume after an error. |
There was a problem hiding this comment.
This comment by me is out of date. Note that we no longer have a %resumptive pragma; we only have %error { abort } { report }, and report gets passed the resumption (of type P a).
The default behavior without %error (calling happyError) or with the unary variant of %error is to call a user-supplied function wrapped in happyReport that ignores the resumption. The reporting function will likely panic and abort the parse (at least happyFail does this). See also the code generation for callReportError.
It's all a bit confusing due to multiple layers of indirection; perhaps we can simplify.
It is probably best to describe the expected behavior of %error { abort } { report } in conjunction with the catch token in the user's guide first. Building on that documentation, we can describe how resumption is implemented here.
|
Superseded by #318. |
This is a wip for introducing
catchTokand all the neccessary generated code in the template files.