What is it?

[joakim]

Hi!

I read your very interesting article on pratt parsing. Is this an implementation of what you described there?

In the next article I will sketch the design described above in code.

I'm looking forward to the follow-up article. Until then, maybe I should read your code, as it appears to contain an article's worth of text in the comments :)

[rljacobson]

Thanks for your interest! Life events kept me from following up with the second article in a reasonable amount of time, and my blog suffered bit rot before I came back to it. I've had bad experiences with static site generators in this respect.

The second article, if and when I write it, isn't intended to go through the Pratt parsing algorithm itself in detail so much as where the parsing logic lives, how it's different from other Pratt algorithm designs, and what the tradeoffs of these design decisions are. The comments in the code don't really get into this. But they probably do stand on their own as an article about how the Pratt parsing algorithm works. I feel like there is already an abundance of articles about that, though.

If I can find the will and energy, I'd also like to return to an aside I made in the first article:

The LToken, NToken, OToken, Affix, and Arity can all be inferred from a single example usage, for example: op1 ? op2 : op3 This suggests that there may be a way to generate a parser for an expression language using nothing but examples. Indeed, there is!

It's an alternative way to a table of encoding operator information that is more human readable and human writable, but it requires extra parsing logic when reading in the operator information. The basic idea is to give examples of operator usage, or at least something very similar to usage. But it's really just cute bells and whistles, to be honest. Not exactly deep stuff.

[joakim]

Life events kept me from following up with the second article in a reasonable amount of time, and my blog suffered bit rot before I came back to it.

No worries, I know how life can be. Sorry for necromancing a blog post from 2020 :)

The second article, if and when I write it, isn't intended to go through the Pratt parsing algorithm itself in detail so much as where the parsing logic lives, how it's different from other Pratt algorithm designs, and what the tradeoffs of these design decisions are.

Aha, that sounds like a great article. But don't feel pressured to write it, I'll take it as a bonus if it should one day appear.

The comments in the code don't really get into this. But they probably do stand on their own as an article about how the Pratt parsing algorithm works. I feel like there is already an abundance of articles about that, though.

You're right, and I've read a few already. But I actually prefer reading comments within code to code within text, so I think I'll give this parser of yours a read to better understand how you've implemented Pratt parsing. IMO, the best way to learn is to read other people's code.

The opportunity to derive operator information from examples caught my attention. It may not be deep stuff, but I think there's more to it than just bells and whistles. Seems to me like it has the power to take something that's tedious and complex and make it much more accessible and understandable. That's rarely wrong. It's an interesting idea that I think is worth pursuing!