Re: [Pyparsing] Get Better Error Messages - Prevent Backtracking

[Eike W. <eik...@gm...>]

I'm really glad that my proposal seems to be usefull for others. I was 
quite astonished how easy it was to implement the idea. So Pyparsing 
is not only an easy to use parsing library, it is also easy to write 
extensions for it. 

On Sunday 20 April 2008 16:58, you wrote:
> I am sorting out what to release in the next version of pyparsing. 
> I will definitely include ErrStop or something similar.  I would
> also like to get an idea of any patterns of usage, to see if there

I use ErrStop in my toy language, which is a crude special purpose 
language. 
http://freeode.berlios.de/
The parser is a pretty long snippet from an even longer file:
http://pastebin.com/f70bba102

> is a natural place to automatically include this feature, in an And
> say.  Or perhaps just incorporate this logic into the And class's

A cooperative And, that treats ErrStop specially, would be great! Then 
one could write:
dataDef2 = Group(Keyword('data') + ErrStop()
                 + attrNameList + ':' + identifier + ';')

> parseImpl method.  Or make raiseErrorStop an attribute of And (or
> maybe just of ParserElement), so that any class can report its
> error location.

An other general method to deal with errors would be the introduction 
of error actions. ParserElement would get a function:
	setErrorAction( callableObject )
The error actions would maybe have the signature:
	errAction( str, loc, error )
 
In the error action the error (ParseException) could be examined, and 
a fatal exception could be raised if desired.

>
> I'm also looking at something like lastParseLoc.  Ideally I'd like
> lastParseLoc to be an attribute of a ParseStatus object that is
> passed through the grammar - this would be a natural home for
> lastParseLoc, as well as things like global debugging flags,
> whitespace character sets, packrat caches, etc.  But I think I
> would also want to pass this object to parse actions, and this
> would break the interface to all existing parse actions.

To keep compatibility you could go the Microsoft way and introduce the 
function:
	setParseActionEx( ... )
Or to let old code run with only minimal changes:
	setParseActionOld( ... )
:-)
>
> :(  So for now, it will probably have to be a class attribute, the
> : same way
>
> that the packrat cache is handled.
>
> So these changes could get pretty drastic.  I'll keep them to a
> minimum for compatability with 1.4.x, maybe bump the minor version
> to 1.5, and save the really drastic changes for 2.0 someday.
>
> -- Paul

Kind regards,
Eike.