> On 10 Jun 2015, at 19:11, Chris Cunningham <cunningham...@gmail.com> wrote:
>
> Inteteresting....
>
> On Wed, Jun 10, 2015 at 9:36 AM, Camille <camille.ter...@gmail.com
> <mailto:camille.ter...@gmail.com>> wrote:
> Hello Pharoers and Moosers,
>
> I did a Pratt parser extension for PetitParser.
>
> <snip>
> @PP Devs:
> I had trouble with the PPContext furthestFailure that is taken into account
> instead of the failures I return, so I had to redefine #parseWithContext: to
> return the failures I want. The results given by furthestFailure were not
> very meaningful in my case (the same is true for PPExpressionParser btw).
> But I guess it was introduced because it gives good results in other cases.
> So would it be possible to change this behavior to let the parser decide if
> it returns the furthestFailure or the original failure?
>
> The intent behind the furthestFailure is that it give the failure that gets
> the furthest into the source stream. It is most useful when there are
> embedded choice operators in the parser - the original/pre furthest behaviour
> would return the last failure, which depending on the incoming stream and the
> order of the choice options could be significantly not useful.
>
> I ran into this when working with the sql parser, which started off with the
> outer choice of (by memory):
> ^ selectStatement / insertStatement / updateStatement / deleteStatement
> If I was trying to part a select statement that had an error at the very end
> of the statement, the parser would return an error talking about how the
> incoming stream failed in deleteStatement. Not useful.
>
> I would be saddened if this further failure was not available.
Yes in that case returning the furthest failure gives better results.
However, this don’t give meaningful messages in all cases.
For exemple with the calculator I gave in my previous message, if I parse ‘1+’
I want to get ‘expression expected at: 2’ but instead it returns ‘$- expected
at 2'.
I’m not proposing to remove this feature but to let parsers decide to use it or
not.
Something like (changes in bold):
PPParser>>parseWithContext: context
| result |
context initializeFor: self.
result := self parseOn: context.
"Return the furthest failure, it gives better results than the last
failure"
(result isPetitFailure and: [ self wantsFurthestFailure and: [ context
furthestFailure notNil ] ])
ifTrue: [ ^ context furthestFailure ].
^ result
PPParser>>wantsFurthestFailure
^ true
Like this, one can return the failures he wants.
PPPrattParser>>wantsFurthestFailure
^ false
Camille
>
> -cbc
