I started implementing this the other day and have reached a point where a lot of these “Rust data structures” are very redundant and bloated. In reality, it seems like I could just ingest the structures into a generic “map” and then only validate them when we execute. It also feels like there should be a much easier way to define these objects with data, instead of data structures. To say a “key” is actually just an object with 1 string parameter and <empty> valid children.

---

Went on a walk and I was thinking more about the idea that maybe every @object “yields” a string in some way, as if they are all functions that resolve or render to a string. This doesn’t actually work, for example a “def” has no use for this, but it’s an interesting idea. `@block` could perhaps just be a way to name a string, and then instead of a literal it could be an @ object that yields a string (like @match). This starts to become sort of a programming language where you just define a tree of data, and then traverse the tree to execute. (A stupid idea flashed through my head, in that “sam” could technically be used to define the tree…)

Anyhow, my goal is to simplify the definition of a legal tree, which really can be done by outlining all the object types by name, their number of parameters, and their legal children (both a list of valid children and their breakpoint object). This means that the parsing logic is data-driven and recursive. So we take in a reference to our object library, as well as our current object.