I don't really understand what implementation of ideas the author is talking about at the end. Is he proposing anything different from existing parser combinators?
From what I read the author seems to abstract the idea of parsing to "transforming data with the possibility of failure". Not sure if I missed the point here
The idea of parsing indeed is to transform data, from a lower level of abstraction to a higher level of abstraction.
Parsing text (a sequence of characters) or binary files (a sequence of bytes) are well known.
The author mentions the case where a JSON parser has generated a bunch of JSON objects, but you want your own object types. (Deserialization libraries can do this automatically if all that is required is setting fields or properties, but for more complex cases you need custom code.)
Similar for XML parsing: all you get is a stream of element events, or a tree of generic XML objects, and you have to transform that further.
Another case would be when you get import data in the form of an Excel or CSV file. Your code starts with a 2D array of generic cells/values, and has to transform it into your own table/object types.
Author here, kind of. Most parser combinators only deal with strings and streams of bytes, but they can also be used for transforming other kinds of data. I think they're pretty useful for working with stuff like JSON or XML and I'd like to see more parser combinator libraries with support for these kinds of data structures. What I tried to do in the post is give names to the different kinds of basic blocks that are needed for parsing all these different kinds of data.
From what I read the author seems to abstract the idea of parsing to "transforming data with the possibility of failure". Not sure if I missed the point here