Reminds me of the new program I started yesterday:
my($state) = 'ok';
my($root) = Tree::DAG_Node -> new({name => 'Root'});
my($value_ref);
try # From the marvellous Try::Tiny.
{
$r -> read(\$input);
$value_ref = $r -> value($root);
}
catch
{
$state = 'exception';
say "Parse exception\n$_";
};
if ($state eq 'ok')
{
if (! $value_ref)
{
$state = 'failed';
say "Parse failed";
}
else
{
check_result($root); # Actions push nodes into this tree.
}
}
On Thursday, 14 August 2014 13:34:49 UTC+10, Christopher Layne wrote:
>
> Let's talk about this common Marpa idiom I use in my own code:
>
> my ($len, $value);
> eval { $len = $parser->read(\$input) };
> if ($@) {
> chomp $@;
> return (undef, $@);
> } elsif (!($value = $parser->value())) {
> return (undef, "Parse failed.");
> }
>
> # empty input streams are $value = \undef
> return ($$value || [], undef);
>
>
>
> My question here is why have two different error paths? The only time I
> ever see value() returning an error is when the input is "looking valid"
> but then abruptly hits EOF. In the 2 cases below, where "Parse failed." is
> returned (which means value() returned undef), the input was valid *up to
> that point*. In the cases where read() returns a failure, the input would
> never have been valid, regardless of EOF or not. Now these are obviously
> intentionally broken unit tests, as it's testing the error handling of the
> grammar, but the part I've always wondered about is why some error cases
> hit read() and some hit value().
>
> The docs say this WRT error-handling:
>
> read():
> A parse is said to be exhausted if, based on the input read so far, there
> is no way for it to continue successfully. Exhaustion is not a problem if
> that Marpa has read all the way to the end of the input, or if it is
> pausing for some other reason. Otherwise, read() treats an exhausted parse
> as a failure.
>
> On failure, read() throws an exception. The call is considered successful
> if it ended because a parse was found, or because internal scanning was
> paused. On success, read() returns the location in the input stream at
> which internal scanning ended. This value may be zero.
>
>
> value():
> The value method call evaluates the next parse tree in the parse series,
> and returns a reference to the parse result for that parse tree. If there
> are no more parse trees, the value method returns undef.
>
>
> Maybe what I'm asking here is why 'partial input' cases are considered
> valid to read() but not valid to value()? If one were to look at the
> language of read(), "there is no way for it to continue successfully",
> wouldn't hitting the end of input be considered "no way for it to continue
> successfully?" In PRD this is usually handled by looking for the token /\Z/
> but I'm not sure how to do the same thing with Marpa or if I should even be
> doing that.
>
What about cases like this (from MarpaX::Demo::StringParser):
sub process
{
<cut>
my($length) = length $string;
<cut>
for
(
my $pos = $self -> recce -> read(\$string);
$pos < $length;
$pos = $self -> recce -> resume($pos)
)
{
<cut code which fiddles $pos>
}
# Return a defined value for success and undef for failure.
return $self -> recce -> value;
} # End of sub,
--
You received this message because you are subscribed to the Google Groups
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
