The other parsers deal with ambiguity by throwing it away.  So, no, they
would not have a problem with excessive ambiguity. :-)

An interesting question is if the only parse not thrown away is actually
the one you want.  If I read the code correctly, you're not actually
evaluating the expressions.  I think it would be important to do so, and to
see if they all produce the same answer.

Also, I note that all test examples are of the form "1+1+1+ [...]".  As the
blog post
<http://blogs.perl.org/users/jeffrey_kegler/2012/08/marpa-v-perl-regexes-a-rematch.html>
Ruslan mentioned details, Marpa::R2 has a higher constant than regular
expressions, but is linear for more grammars than any other parser out
there.  So the pattern is that regexes are a huge win on the simple ones,
and a huge loss once regexes start going linear.


On Sat, Jun 18, 2016 at 4:03 AM, <[email protected]> wrote:

> Thanks, my initial googling didn't point to the Scanless/R.pod document.
> Anyway I didn't raise the limit and simply modified the grammar to be like
> in Scanless/DSL.pod. I entirely don't understand why the previous grammar
> was considered too ambiguous by Marpa though, will it seems to be doing
> okay with perl regex or Regexp::Grammars or perl 6. The right associativity
> now works though.
>
> The new version improves the speed, but not drastically [1]. As the number
> of terms in the benchmark expression (1+1+..+1) is increased to hundreds
> and up to a thousand, the Marpa version seems to be close to 3x slower than
> the regex version.
>
> [1]
> https://metacpan.org/pod/release/PERLANCAR/Bencher-Scenarios-PERLANCARParseArithmetic-0.004/lib/Bencher/Scenario/PERLANCARParseArithmetic/parse_arithmetic.pm
>
> On Saturday, June 18, 2016 at 10:49:16 AM UTC+7, Jeffrey Kegler wrote:
>>
>> Quick answers for 2 & 3
>>
>> 2.) See
>> https://metacpan.org/pod/distribution/Marpa-R2/pod/Scanless/R.pod#too_many_earley_items
>> for how to raise this limit or eliminate it entirely.  Although, the fact
>> you are hitting this limit is almost always a sign your grammar is too
>> ambiguous.
>>
>> 3.) Look at the grammar in the synopsis of
>> https://metacpan.org/pod/distribution/Marpa-R2/pod/Scanless/DSL.pod.
>> You are breaking your arithmetic expression into separate statements and
>> "assoc => right" is only effective within a single precedenced statement.
>> This means the way you wrote it, it has no effect.
>>
>> Doing a precedenced statement for 3) may fix 1) and 2)  as well.  These
>> answers are off the top of my head and untested.
>>
>>
>> On Fri, Jun 17, 2016 at 8:22 PM, <[email protected]> wrote:
>>
>>> Hi guys,
>>>
>>> I've been using Perl 5.010 regex to do some parsing, e.g. in Data::Csel
>>> [1] to parse CSS-selector-like expression, due to its relatively low
>>> startup overhead compared to Marpa or Regexp::Grammars. A couple of days
>>> ago, after reading about a topic in perl6 subreddit [2], I did a comparison
>>> benchmark [5] for a simple arithmetic parser using perl [3] vs Marpa [4].
>>> My questions:
>>>
>>> 1) how do I improve the Marpa version's performance?
>>> 2) how to remove the "Earley item count (N) exceeds warning threshold"?
>>> This happens for 1+1+..+1 (100x) expression but not for the 20x or below.
>>> 3) how do I make right associativity work? The Marpa version still
>>> evaluates ** operator left to right.
>>>
>>> regards,
>>> perlancar
>>>
>>> [1] https://metacpan.org/pod/Data::CSel
>>> [2] https://www.reddit.com/r/perl6
>>> [3]
>>> https://metacpan.org/pod/release/PERLANCAR/PERLANCAR-Parse-Arithmetic-0.001/lib/PERLANCAR/Parse/Arithmetic.pm
>>> [4]
>>> https://metacpan.org/pod/release/PERLANCAR/PERLANCAR-Parse-Arithmetic-0.001/lib/PERLANCAR/Parse/Arithmetic/Marpa.pm
>>> [5]
>>> https://metacpan.org/pod/release/PERLANCAR/Bencher-Scenarios-PERLANCARParseArithmetic-0.002/lib/Bencher/Scenario/PERLANCARParseArithmetic/parse_arithmetic.pm
>>>
>>> --
>>> 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.
>>>
>>
>> --
> 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.
>

-- 
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.

Reply via email to