Yes I'm vague on Data::Dumper and I don't know much about the workings of Marpa.
I added on the example code for Marpa::R2::ASF so I can compare it with my real code. It doesn't seem to be ambiguous now but I actually can't see what's different about it. I'm not sure whether I simplified it too much when I made the analogy. I want rules that mean "only interpret a consonant as an abbreviation" when it can't be interpreted as part of a syllable. I don't know if that's possible of course (-: I'll see if I can come up with a better analogy based on some actual ambiguities I find in Lao. On Thursday, 4 September 2014 13:58:23 UTC+10, Jeffrey Kegler wrote: > > What rns did (as I read it) was list all the results of $slr->value(). > The parse is unambiguous if and only if there is exactly one, which seems > to be the case here. (You've been away from Perl, so Data::Dumper may now > be hard to read, but you can confirm this for yourself by adding a line > before the dump of each value, as a "hi there", or giving a count.) > > Is your rule that you don't want to allow an abbreviation to follow a > vowel? > > -- jeffrey > > On 09/03/2014 08:24 PM, Andrew Dunbar wrote: > > Do we know if that's ambiguous? Don't we have to run it > through Marpa::R2::ASF to know? > > > > On Wednesday, 3 September 2014 20:10:42 UTC+10, rns wrote: >> >> Can you please look at this gist >> <https://gist.github.com/rns/fb6abf62a5fa779957ba>? The result is in the >> comment below it. This might be a solution provided that I've got the right >> idea. >> >> >> >> >> >> >> On Wed, Sep 3, 2014 at 11:44 AM, Andrew Dunbar <[email protected]> >> wrote: >> >>> I've come back to Perl after a long absence just to play with Marpa >>> because it looks like the most full featured Earley parser in any of the >>> programming languages I know. >>> >>> I'm interested in Earley specifically because it can handle ambiguity >>> and can produce a parse forest. >>> >>> I'm using it to investigate the syllable structure of the writing >>> system of the Lao language of Southeast Asia. Specifically to see whether >>> it's inherently ambiguous, and how. >>> >>> So far it works great and I'm glad I've come here from the Bison and >>> PEG grammars I was playing with earlier. >>> >>> But it seems that there might be two kinds of ambiguities, the kind >>> I'm looking for, and a kind that might be an artefact of Earley parsing or >>> of the way I've written the grammar. >>> >>> Without having to teach you Lao I'll attempt to analogize: >>> >>> All ::= Syllable+ >>> >>> Syllable ::= C V C >>> | C V >>> | C >>> >>> C ~ [bcdfghjklmnpqrstvwxyz] >>> V ~ [aeiou] >>> >>> >>> The "Syllable ::= C" rule is to allow lone initial consonants, as are >>> used occasionally for abbreviations. >>> >>> If my input string is "mat" I only want: >>> >>> (Syllable (C m) (V a) (C t)) >>> >>> But due to the abbreviation rule I also get a second unwanted parse: >>> >>> (Syllable (C m) (V a)) >>> (Syllable (C t)) >>> >>> I've been able to refactor my grammar to deal with other issues that >>> have appeared, by I can't seem to think of anything which accounts for >>> occasional abbreviations but doesn't generate a number of unwanted >>> alternative parses. >>> >>> Can I refactor my grammar or is there some other way to deal with this >>> but still generate all the other kinds of ambiguity that I am interested in? >>> -- >>> 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] <javascript:>. > 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.
