That sounds really cool and useful extension.

Regarding the furthest failure, the core of the problem is the distinction between an error and a failure. Error reports on a problem in the input, while failure is information for choice parser combinator. In general, the furthest failure is a better approximation of an error than the last failure, so we use it.

I am not sure what exactly is the problem in case of PrattParser. I guess the last failure gives better results for a user? One has to consider a pratt parser included in the normal parser, e. g. Expressions parsed by pratt in a Java Grammar. Depending where an error occurs, different strategy for choosing the proper failure is necessary :-/

Regarding tokenization, there is a message token, that returns PPTokenParser, which transforms a parsed input into the PPToken object. Perhaps this might be helpful?

Cheers Jan


On Wed, Jun 10, 2015, 20:52 Richard Sargent <richard.sargent@gemtalksystems.com> wrote:
camille teruel wrote
>> On 10 Jun 2015, at 19:11, Chris Cunningham &lt;

> cunningham.cb@

> &gt; wrote:
>>
>> Inteteresting....
>>
>> On Wed, Jun 10, 2015 at 9:36 AM, Camille &lt;

> camille.teruel@

>  &lt;mailto:

> camille.teruel@

> &gt;> 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

This screams at me. Why not just delegate to the context and use a context
that returns the preferred failure? e.g. end with:
^context preferredResultFor: result.


>
> PPParser>>wantsFurthestFailure
>       ^ true
>
> Like this, one can return the failures he wants.
>
> PPPrattParser>>wantsFurthestFailure
>       ^ false
>
>
> Camille
>
>>
>> -cbc





--
View this message in context: http://forum.world.st/Pratt-Parsers-for-PetitParser-tp4831456p4831486.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.