Optionality is a convenient way to model failure, but can only take us so far. We will scrutinize how we model errors in our parsing library and the problems that have come out of it, and we will address these problems by changing the fundamental shape of the parser type. In doing so, we will be in a good position to layer context onto failures, and make it easy to see exactly where and why a parser failed.
By this point we have taken a deep dive into many different topics of parsing, from ergnomics and generalization, to performance and error messaging. But there’s a closely related concept that is also very important to discuss, and that’s “printing”. It can be thought of as the inverse of parsing in that it transforms well-structured data back into nebulous data. Incredibly, parsing and printing can be unified into a single, composable unit.
