🔒 We conclude our series on invertible parsing by converting a more complex parser into a parser-printer, and even enhance its format. This will push us to think through a couple more fun parser-printer problems.

🔒 We've had to really stretch our brains to consider what it means to reverse the effects of parsing, but let's looks at some parsers that take it to the next level. They will force us to reconsider a fundamental part of printing, and will make our printers even more powerful.

🔒 Our parser-printer library is looking incredible, but there's a glaring problem that we have no yet addressed. We haven't been able to make one of our favorite operations, `map`, printer-friendly. The types simply do not line up. This week we will finally address this shortcoming.

🔒 Our parser-printer library is looking pretty impressive, but there are a couple problems we need to address. We have made some simplifying assumptions that have greatly reduced the generality our library aspires to have. We will address them by abstracting what it means for an input to be parseable _and_ printable.

🔒 We will chip away at more and more parser printer conformances, some of which will truly stretch our brains, but we will finally turn our complex user CSV parser into a printer!

🔒 Now that we've framed the problem of printing, let's begin to tackle it. We will introduce a `Printer` protocol by "reverse-engineering" the `Parser` protocol, and we will conform more and more parsers to the printer protocol.

🔒 We've spent many episodes discussing parsing, which turns nebulous blobs of data into well-structured data, but sometimes we need the "inverse" process to turn well-structured data back into nebulous data. This is called "printing" and can be useful for serialization, URL routing and more. This week we begin a journey to build a unified, composable framework for parsers and printers.

🔒 Let's make errors a pleasure to encounter! We will make them easy to read, add more context to make them easy to debug, and even see how error messages can influence existing APIs.

🔒 Let's explore the topic of error handling. 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.

🔒 So what is the point of parser builders anyway? We will leverage our new builder syntax by rewriting a couple more complex parsers: a marathon parser and a URL router. This will lead us to not only clean up noise and tell a more concise parsing story, but give us a chance to create brand new parsing tools.