Note that max_parses => N, means "allow any number of parses, but only
report the first N" -- that's different from the question of whether or
not to warn the user about ambiguity. The typical use case for
max_parses is a situation (such as testing) where a lot of parses is
possible or even OK, but you want to put a limit on the number
reported. Marpa (in common with Earley's original algorithm) stores
parses in a compact form. It's quite possible for the parser to run in
reasonable time, but for there to be an exponential number of parses, so
that printing them out would take far more than a reasonable amount of
time. 'max_parses' is about that kind of situation.
So 'max_parses' is not really relevant here.
-- jeffrey
On 08/14/2014 04:15 PM, Christopher Layne wrote:
On Aug 14, 2014, at 1523 PT, Ron Savage <[email protected]> wrote:
Questions:
Are these for C or Perl or both?
1.) What should be its name? [Probably not doit() ].
I'd like it to be called process().
process() as an additional method also sounds find to me, although it's a bit
non-parser like. However, the latter probably doesn't matter as it's an OO
interface, and $parser->process() does make sense in that context.
2.) I think doit() should throw an exception on error -- that's most
convenient in simply apps. Does that sound right?
Yes, if it ties in with Try::Tiny being the recommended handler at the Perl
level.
That means $_ will hold the msg.
An exception is fine for this, as read() already throws exceptions.
3,) Also, doit() could catch ambiguous parses, and throw an error on
those, with an error message indicating where the ambiguity happened.
Currently ambiguity must be explicitly checked for. If you don't, and
it's a problem, you (in effect) have a silent error condition. Should I
treat ambiguous parses as errors?
Could that be an option?
This is already an option and I think it should stay that way:
my $parser = Marpa::R2::Scanless::R->new({
grammar => $grammar,
semantics_package => $semantics_package,
trace_terminals => $debug,
trace_values => $debug,
max_parses => 1, <------------------ this
}) or die;
However, I think we should consider changing max_parses to be 1 by default. I'd
imagine the vast majority of people want an ambiguous parse tree result to be
the exception rather than norm and for those parties who want to take advantage
of it, they can simple set max_parses to their own value (or 0/-1 or something
along those lines).
-cl
--
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.
