Implementing the mechanics [Parser Combinators From Scratch] Episode 2

In this episode we explore how the primary mechanism of parser combinators works: A function that transforms one parser state into another. We implement the str and sequenceOf parsers, as well as a internal error handling mechanism.

=[ ℹ About ℹ ]=

During this series we will develop an understanding of the concept of parsing, and build our own parser combinator system from scratch. The system we build will be capable of parsing both binary and text data. We'll make use of both object-oriented and function programming principles to develop an effective and intuitive library.

=[ 🔗 Links 🔗 ]=

[VivekHaldar]

Love seeing boutique focused channels like this. Keep it up!

[jma]

I cant speak how much thankful I am now that I saw your channel. This gave me quite a good understanding now about parser combinators which I failed to do after reading some articles and few repositories on how they would really work.

[adamwirth]

oh my gosh I love the "flashback" filter you added to the beginning haha. this is great

[vespertilian]

This content is gold, thank you for starting this channel!

[GearsDatapacks]

Great series! Easy to understand, and I have also been looking for something lie this for a while, but this is the first that I found.

[mladjo]

Great series. Very well explained with great examples and with a good pace. Keep it up.

[Drumstix]

Great stuff. I'm interested in seeing more for sure. Good dialog with reasoning behind each of the changes, and it's nice to following along with the refactoring process.

[knowjop]

That for of loop at 10:00 is an excellent candidate for a little one line reducer:

const result = parsers.reduce((state, p) => p(state), initialState);

[thehaptiK]

hi, . good luck with the series. much love

[manantank]

shouldn't we check for error in for-of loop also before pushing the result in results ?

for (let p of parsers) {
newState = p(newState);
if (newState.isError) break; <--- ?

}

[RepertoireSix]

For some reason I'm having trouble reading "functions returning other functions" with arrow notation. Written "as usual" (explicitly defining both functions with the function-keyword and returning the inner one") makes a lot more sense to me. Maybe cause I've done it quite a lot in Python with decorators. I do get how arrow functions work and I do use them a lot in my other programs. Anyways, this seems like a cool series and there's nothing wrong with the style you've chosen, I just find it funny that even though I get the concept, the notation makes it more confusing for me. I'll definitely check out the rest of the series, maybe the arrow function style become easier to read as time goes on too.
As a side note, I got a recommendation for a 16bit JS computer series you have going on, haven't checked it out yet, but I will. Have you heard of the Synacor challenge? I tried it a couple of years ago, but I wasn't good enough of a programmer back then. Do you think the concepts you talk in your series would help in actually completing the Synacor machine?

[duyle-uiul]

Great. I love this series a lot. Thanks <3