The only differences between a State and a StateLazy parser are the instance of Applicative, and the type (and implementation) of runParser. We therefore need to newtype the original Parser type, to allow it to have a different instance.

A return type like Either, that distinguishes not only between right and wrong answers, but also has commitment, so that a failure cannot be undone. This should only be used for writing very primitive parsers - really it is an internal detail of the library. The z type is the remaining unconsumed input.

Apply a parser to an input token sequence.

Simply return the next token in the input tokenstream.

Succeed if the end of file/input has been reached, fail otherwise.

Return the next token if it satisfies the given predicate.

p onFail q means parse p, unless p fails, in which case parse q instead. Can be chained together to give multiple attempts to parse something. (Note that q could itself be a failing parser, e.g. to change the error message from that defined in p to something different.) However, a severe failure in p cannot be ignored.

Update the internal state.

Query the internal state.

Deliver the entire internal state.

Push some tokens back onto the front of the input stream and reparse. This is useful e.g. for recursively expanding macros. When the user-parser recognises a macro use, it can lookup the macro expansion from the parse state, lex it, and then stuff the lexed expansion back down into the parser.

The PolyParse class is an abstraction gathering all of the common features that a two-level error-handling parser requires: the applicative parsing interface, the monadic interface, and commitment.

There are two additional basic combinators that we expect to be implemented afresh for every concrete type, but which (for technical reasons) cannot be class methods. They are next and satisfy.

The Commitment class is an abstraction over all the current concrete representations of monadic/applicative parser combinators in this package. The common feature is two-level error-handling. Some primitives must be implemented specific to each parser type (e.g. depending on whether the parser has a running state, or whether it is lazy). But given those primitives, large numbers of combinators do not depend any further on the internal structure of the particular parser.

Apply a parsed function to a parsed value. Rather like ordinary function application lifted into parsers.

x discard y parses both x and y, but discards the result of y. Rather like const lifted into parsers.

When a simple fail is not strong enough, use failBad for emphasis. An emphasised (severe) error cannot be overridden by choice operators.

adjustErrBad is just like adjustErr except it also raises the severity of the error.

Parse the first alternative in the list that succeeds.

Helper for formatting error messages: indents all lines by a fixed amount.

'exactly n p' parses precisely n items, using the parser p, in sequence.

'upto n p' parses n or fewer items, using the parser p, in sequence.

Parse a non-empty list of items.

Parse a list of items separated by discarded junk.

Parse a non-empty list of items separated by discarded junk.

Parse a list of items, discarding the start, end, and separator items.

Parse a bracketed item, discarding the brackets. If everything matches except the closing bracket, the whole parse fails soft, which can give less-than-satisfying error messages. If you want better error messages, try calling with e.g. bracket open (commit close) item

manyFinally' is like manyFinally, except when the terminator parser overlaps with the element parser. In manyFinally e t, the parser t is tried only when parser e fails, whereas in manyFinally' e t, the parser t is always tried first, then parser e only if the terminator is not found. For instance, manyFinally (accept "01") (accept "0") on input "0101010" returns ["01","01","01"], whereas manyFinally' with the same arguments and input returns [].