COLLECT
Last night when I was trying to work through this problem, I think I was too deep in the weeds to wrap my head around what I needed to do. Having some space now, I might be able to get a bit further. Essentially, I need a way to traverse groups at execution time. It doesn’t make sense to pre-bake these lists, because there’s no way to guarantee if they’ll be used; so we’ll traverse the groups as they arise. However, we can and probably should cache these traversals as we go, because it is likely that we’ll access the same object several times. This means that from any given “object”, we may try to access its next and previous items along one of its groups. To do that, we need to take the object’s id, and find the next or previous element. If we’ve already resolved this traversal, we can cache it.
Honestly, perhaps we can actually just create a sort of ‘linked list’ while generating the context; all we’d need to do is walk through the tree after all maps are imported, and let each “group node” know the key of the next and previous elements. This might be unnecessary overhead, but it might not be too bad if we batch it. How would we use this information? Maybe instead of the group just storing the name of the map, we have a struct there that contains the &Map, and an Option<usize> index for prev/next.
---
This approach worked very well, and after sorting out a few other small questions about unrefined syntax, the entire first draft of this system is now working; it executes queries, iterates lists, and rendering text from loaded objects and the context. I should do a bit more testing, and I’d like to add a solution for nested indentation, but I’m glad that the big lift is over.
===
CO
As I wrapped up the little text language (collect) I was reading a bit more of SICP and got to the topic of recursion. I realized that Co (and CODA) are both incapable of compositional recursion, which would limit their application. After thinking about it in the shower for a while, I realized that this is not the case. In the case of instructions, I will need to add an opcode to “load the address of this routine into memory”, and from there I can just pass the instruction opcode on the stack and call it; can potentially get messy, but recursion is possible like this without an unresolvable hash loop.
With data, it’s a bit more philosophical: two people cannot be each other’s parents, because of causality. Therefore, two pieces of data cannot be mutually composed. Instances where data is connected are always in the form of relationships. This is something I have already thought about, but had forgotten. If you ever need two pieces of data to be connected, they must both already exist, and you can connect them with a new "relationship" piece of data.