I have a grammar that is quite ambiguous. Ambiguities aren't solved easily because the grammar is quite complex and the task of resolving ambiguity is probably not possible. Ambiguities are supposed to be solved later after establishing some context in which it can be resolved.
The biggest source of parsing failures I have because in the alignment of the matching rules a short match often prevents a long match from being found. And I wonder if I can look for the longest match with petit parser. Combining parsers with / always finds the first matching and | does not find anything if more than one rule matches. Any advize how to do this with petit? Norbert _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Order your choices from the longest to the shortest.
If you don't know the longest match statically (from the grammar) but only from the input, you could define your own choice operator along the following lines (untested code): LongestChoiceParser>>parseOn: aStream | start element longestEnd longestElement | start := aStream position. 1 to: parsers size do: [ :index | element := (parsers at: index) parseOn: aStream. (longestEnd isNil or: [ longestEnd < aStream position ]) ifTrue: [ longestEnd := aStream position. longestElement := element ]. aStream position: start ]. aStream position: longestEnd. ^ longestElement Lukas On 26 July 2011 12:25, Norbert Hartl <[hidden email]> wrote: > I have a grammar that is quite ambiguous. Ambiguities aren't solved easily because the grammar is quite complex and the task of resolving ambiguity is probably not possible. Ambiguities are supposed to be solved later after establishing some context in which it can be resolved. > > The biggest source of parsing failures I have because in the alignment of the matching rules a short match often prevents a long match from being found. And I wonder if I can look for the longest match with petit parser. Combining parsers with / always finds the first matching and | does not find anything if more than one rule matches. > > Any advize how to do this with petit? > > Norbert > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Am 26.07.2011 um 12:56 schrieb Lukas Renggli: > Order your choices from the longest to the shortest. Yes this is the normal choice to reorder were possible. > > If you don't know the longest match statically (from the grammar) but > only from the input, you could define your own choice operator along > the following lines (untested code): > > LongestChoiceParser>>parseOn: aStream > | start element longestEnd longestElement | > start := aStream position. > 1 to: parsers size do: [ :index | > element := (parsers at: index) > parseOn: aStream. > (longestEnd isNil or: [ longestEnd < aStream position ]) ifTrue: [ > longestEnd := aStream position. > longestElement := element ]. > aStream position: start ]. > aStream position: longestEnd. > ^ longestElement > Norbert > > On 26 July 2011 12:25, Norbert Hartl <[hidden email]> wrote: >> I have a grammar that is quite ambiguous. Ambiguities aren't solved easily because the grammar is quite complex and the task of resolving ambiguity is probably not possible. Ambiguities are supposed to be solved later after establishing some context in which it can be resolved. >> >> The biggest source of parsing failures I have because in the alignment of the matching rules a short match often prevents a long match from being found. And I wonder if I can look for the longest match with petit parser. Combining parsers with / always finds the first matching and | does not find anything if more than one rule matches. >> >> Any advize how to do this with petit? >> >> Norbert >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
> thanks, it works. Do you plan to integrate that in petit parser? I wonder if it would be feasible to implement yet another binary selector for another parser. I use /> at the moment.
I've added it to PetitBeta using the proposed operator #/>. Name: PetitBeta-lr.51 Author: lr Time: 28 July 2011, 10:13:33 am UUID: ff87b4d9-b874-47fe-b85a-ee80b2321fa0 Ancestors: PetitBeta-lr.50 - added PPLongestChoiceParser to experimental > > Norbert >> >> On 26 July 2011 12:25, Norbert Hartl <[hidden email]> wrote: >>> I have a grammar that is quite ambiguous. Ambiguities aren't solved easily because the grammar is quite complex and the task of resolving ambiguity is probably not possible. Ambiguities are supposed to be solved later after establishing some context in which it can be resolved. >>> >>> The biggest source of parsing failures I have because in the alignment of the matching rules a short match often prevents a long match from being found. And I wonder if I can look for the longest match with petit parser. Combining parsers with / always finds the first matching and | does not find anything if more than one rule matches. >>> >>> Any advize how to do this with petit? >>> >>> Norbert >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Am 28.07.2011 um 10:14 schrieb Lukas Renggli: >> thanks, it works. Do you plan to integrate that in petit parser? I wonder if it would be feasible to implement yet another binary selector for another parser. I use /> at the moment. > > I've added it to PetitBeta using the proposed operator #/>. > > Name: PetitBeta-lr.51 > Author: lr > Time: 28 July 2011, 10:13:33 am > UUID: ff87b4d9-b874-47fe-b85a-ee80b2321fa0 > Ancestors: PetitBeta-lr.50 > > - added PPLongestChoiceParser to experimental > Norbert >> >> Norbert >>> >>> On 26 July 2011 12:25, Norbert Hartl <[hidden email]> wrote: >>>> I have a grammar that is quite ambiguous. Ambiguities aren't solved easily because the grammar is quite complex and the task of resolving ambiguity is probably not possible. Ambiguities are supposed to be solved later after establishing some context in which it can be resolved. >>>> >>>> The biggest source of parsing failures I have because in the alignment of the matching rules a short match often prevents a long match from being found. And I wonder if I can look for the longest match with petit parser. Combining parsers with / always finds the first matching and | does not find anything if more than one rule matches. >>>> >>>> Any advize how to do this with petit? >>>> >>>> Norbert >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Free forum by Nabble | Edit this page |