roc-lang / book-of-examples

Software Design by Example in Roc
Other
23 stars 15 forks source link

topic proposal: Parser combinator library #45

Open monmcguigan opened 1 month ago

monmcguigan commented 1 month ago

Something that could be quite fun and useful to do is showing how to implement a simple parser combinator library.

Could build on some of the BSON encoding/decoding, where we can take that shape of data and show how you would extend it to parse it into the ADT representing it.

I'd include showing how to combine simple operations for parsing like A | B, A ~ B, as well as for simple data types like strings, bools, digits etc.

isaacvando commented 1 month ago

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 commented 1 month ago

:+1: from me - @monmcguigan will this be in addition to the JSON codec?

isaacvando commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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!