Coding 2023-07-16

By Max Woerner Chase

I went over the parser code for Lox a bunch, and I think the interfaces make sense now. At this point, the functor requires two simple modules, instead of three with a complicated relationship between them, so at minimum, the code is simpler now just because I'm not trying to use features that I think I have some serious gaps in my understanding of.

At this point, the only code missing for the basic parser case is... the code that actually handles parsing. The hurdle to clear there is that I need to figure out the types required to handle the "items". It's like I need to consider every phase of the parsing process simultaneously to figure out what data is actually needed. But, like, there must be some way to break this down...

The state sets are stored in an array. The sets themselves should be NMaps containing sets of partially completed rules, and start indices. I'm not sure whether some of these will need to carry information about semantic actions, or if I can safely just leverage the grammar to retrieve them. Let's assume the latter.

It may be the case that I want items derived from a successful scan to carry the matching terminal symbol. That could also be in a tuple with the map, or simply not stored within the array. Because of those latter two options, let's assume that it's not stored inside the items. My idea for the structure of the items is to have two lists of symbols like a zipper list, and for the queued form, to take the Cartesian product with the relevant symbol type. This means that each queue has a different type, which will match up with the action associated with that queue.

Now that I understand the queue types, I should hopefully be able to write them out properly and get the flow between them correct. Unfortunately, to actually implement this, I'm going to need to either get really clever with pure functions, or bite the bullet and write a bunch of imperative stuff.

I'll think about that over the next few days or whatever.

Good night.