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.
