Sure, I plan to cover the resolver algorithm in the write-up I'll start working on this weekend. The core idea is like the textbook DFS algorithm for topological sort. If you know how to implement a recursive DFS with 'visited' flags on nodes to detect cycles, it's a similar idea to how the resolver works via resolve_sym. There's another variant of recursive DFS which uses monotonic timestamps. We're going to add something similar soon since it lets you print the symbol path that led to a cycle: when a cycle is detected (from a non-monotonic timestamp sequence), sort all the SYM_RESOLVING symbols by timestamp and print them in order. You could also reconstruct the path by manually maintaining a path stack in parallel to the resolve_sym call stack. But all of these things are just DFS topological sorting in various guises. The thing that's different from textbook DFS is that we aren't just doing the topological sort as a separate pass but intermingled with everything else in the resolve pass, especially type checking.
For version 0 there's no plan for an easy way to support stretchy bufs. We might add special support for dynamic arrays in some later iteration, but there's no short-term plans. But you can do what you've always done in C, which is implement each type instance manually, sharing what is possible/reasonable. Then the manual per-instance code is limited, e.g.
| func buf_push(buf: void**, elem_ptr: void*, elem_size: size_t);
func int_buf_push(buf: int**, elem: int) {
buf_push(buf, &elem, sizeof(elem));
}
|
Or you could just call the generic buf_push directly at each call site.
That's even assuming you want a stretchy buf style interface. Other approaches to dynamic arrays might be equally good or better once you start doing a bit of custom code per instance.
Stretchy bufs are mainly valuable for prototyping (e.g. all the current uses in the Ion compiler will probably be replaced by something more custom). Having them available is great for productivity but it doesn't take a lot of time to write out a specific type instance by hand when you already have elem_size-parameterized generic versions based on void pointers.
Again, we might do language-level support for something like stretchy bufs later, but it's not really a show stopper, just a minor inconvenience, like the other compromises we're making.