Coding 2023-07-26
I do have some other ideas that I'm turning over in my head to see how I could express them in OCaml, but the current result there is "seemingly pretty poorly". Like a bunch of really messed-up functors...
So, let's get back to Lox. By which I mean, the stuff that Crafting Interpreters specifically recommends against doing, in the effort to implement Lox.
I'm trying to figure out the right structure for the state sets and the "work queue". Because I want to augment the state sets with additional information, let's temporarily call them something else, like "cells". When we're working with cell #n, then we need access to possibly every cell from 0 to n inclusive, as well as "the current work queue" and "the next work queue".
There are several operations that call each other recursively.
- Adding an item to a work queue consumes the old version of the queue, and returns a new one. Additionally, it updates the cell corresponding to the work queue...
- Predicting an item consumes from a work queue (consumes and returns a new version), and updates the corresponding cell
- Scanning an item consumes from a work queue and the current token and updates the corresponding cell
- Completing consumes from a work queue and potentially any cell, and updates the corresponding cell.
Here's what my gut says to do to implement all of this:
- Have a pair of cell and work queue.
- Have a pair of those.
- Do not add the "current" cell to the array until it is done being processed; special-case getting it in the completion code.
- Have each function operate on the pair of data structures, taking it in and returning it.
- Maybe define some kind of fixpoint helper to replace all of the loops.
All of this gives me a reasonable target to shoot for later, so I'm feeling good about it now. I'm going to wrap up for now and mess with the other ideas on paper.
Good night.