Next: Parse diagnosis checklist, Previous: Listing Earley sets, Up: Tracing and diagnosing parses [Contents][Index]
The parse diagnostics should include a facility for
displaying the token processing.
At the default verbosity level,
the facility should describe the token
passed to the
marpa_r_alternative
(see marpa_r_alternative)
method call,
and specify the outcome of
the marpa_r_alternative
method call as
“accepted”, “rejected” or “uncorrectable”,
where
marpa_r_alternative() call succeeded;
marpa_r_alternative() call failed,
but the failure is fully recoverable; and
marpa_r_alternative() call failed,
but the failure is not fully recoverable.
The token tracing facility’s reporting of rejected tokens can vary by application. For some applications, token rejection will not be allowed, so that distinguishing between rejected and uncorrectable tokens is pointless and unnecessary. For other applications, such as those that use the Ruby Slippers technique (see Ruby Slippers), token rejection will be a common occurrence in normal processing.
At some verbosity level above the default,
after every
marpa_r_earleme_complete() method call
(see marpa_r_earleme_complete)
the token tracing facility should list all the
expected tokens.
The marpa_r_terminals_expected()
(see marpa_r_terminals_expected) method call
is available for this purpose.