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
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.
Norbert
On 26 July 2011 12:25, Norbert Hartl <norbert(a)hartl.name> 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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev