Combinators are all of type Input -> (Output, Input)?. This is sufficient to reject parses, parse forwards, and even to implement zero-width negative lookahead or more esoteric things (e.g. it’s trivial, although of dubious value, to implement parsers which swap out the input string for parsers following them), but it doesn’t allow lookbehind.
We should instead return an index into the input collection; then we can loosen #67’s recursive Sliceable constraint to arbitrary CollectionTypes. That would give us:
(We could also parameterize by a second collection type, such that each combinator could initiate parsing into not simply a different collection but a different kind of collection, but again, this is of dubious value.)
Combinators are all of type
Input -> (Output, Input)?
. This is sufficient to reject parses, parse forwards, and even to implement zero-width negative lookahead or more esoteric things (e.g. it’s trivial, although of dubious value, to implement parsers which swap out the input string for parsers following them), but it doesn’t allow lookbehind.We should instead return an index into the input collection; then we can loosen #67’s recursive
Sliceable
constraint to arbitraryCollectionType
s. That would give us:If we have a use case for swapping the parsed collection, we could add the collection to the return value as well:
(We could also parameterize by a second collection type, such that each combinator could initiate parsing into not simply a different collection but a different kind of collection, but again, this is of dubious value.)