I started implementing this yesterday, and I have a baseline context being built, with all of the objects and groups being assembled. Now I’m working on the resolver. When resolving an object, what can happen? In some cases, the object resolves to a string, like with a @render tag. In other cases, it might have a side effect like writing to a file with an @export. What else can happen? A @match resolves to a string, technically a @block resolves to a string too, though both of those only resolve when asked explicitly, not automatically. Maybe a @write can write to the stdout. Seems like really the only thing a resolve can do is a side effect or return a string.

---

After thinking on a walk, I also realized that “@render” should really only be run when called from a string $ function; effectively the $ function means “select this object and render it”. This leaves other objects to mean other things for resolving, which is probably just “@execute (or @run?)”, “@iterate@“, “@export” and the like. So really I think that once you build a context, you “execute” it. Should I extract out all of the executable objects in the context?

---

I started running into some bottlenecks with my context’s halfway approach of “sort of a map but sort of not”. I don’t get the benefit of just accessing objects by name, but I also don’t get the benefit of strongly typed data. This makes for a lot of checking keys and resolving predicates on lists, and it’s just really ugly and non-ergonomic. I don’t really want to take on the work and constraints of strongly typing everything, so perhaps it makes more sense to fully generalize the system.