topic proposal: Parser combinator library about book-of-examples

[isaacvando]

Agus and I talked about how we should approach parsing yesterday, and with the idea we have in mind at the moment, I don't think it makes sense to have a separate parser combinators chapter. Agus is going to write his HTML parser using a direct approach to passing state and with good error messages. Then in the template engine chapter, I can build on the approach Agus took earlier to introduce parser combinators. The template chapter should work well as a motivating example because it will show how the other approach would get unwieldy, and how combinators make the code easier to read and write.

[monmcguigan]

Just read through the zulip thread, that all makes sense to me. What I had in mind for this proposal was based on an implementation for a simple parser combinator library I worked on in Scala, here. I like your plan for showing the problem you're trying to solve first, then abstracting over it in the later chapter, so having a whole other chapter decided to parsers is probably a little overkill.

[rtfeldman]

I don't know if it's the right fit for this book, but I think there's an opportunity to talk about more than just the API design of parser combinators. If each chapter is supposed to be about an hour, I definitely think an "advanced parsing" or "advanced parser combinators" chapter could fill up an hour easily!

For example, the "Backtracking" and "Tracking Context" (and error messages considerations) mentioned in elm/parser can take awhile to explain, but are very useful things to know about when working with parsers!

[isaacvando]

Agus and myself are both doing some parsing for our chapters (the html parser and html template). I opened a topic on Zulip to discuss how we should introduce parsing in the book. I think having a chapter for parser combinators could definitely fit in!

[gvwilson]

👍 from me - @monmcguigan will this be in addition to the JSON codec?