That sounds very reasonable to me. -cbc
On Wed, Jun 10, 2015 at 10:45 AM, Camille <camille.ter...@gmail.com> wrote: > > 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> 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 > > >
