Spending too much time thinking about a byteco iterator without really knowing what I’d use it for. The two main uses cases are for creating a debug string and for compiling symbols. Honestly, in both cases it would make more sense within Rust to be converting the raw bytes into a native data type instead of just wrangling raw bytes. Right now what I should be doing is implementing the resolve function that reads through byteco and makes sure every import resolves in the library, and that every used name has either an associated local name or imported name. Perhaps we should check anchors too? And maybe even expand the macros to see that they all work? What is the end of the responsibility for this function? Probably it should do all of these things. One function to make sure that the syntax is all good, another that validates the semantics. Running a module through both should mean it is ready to assemble or export. This has weird implications for macros though, because there is no guarantee that a macro will compile; it can only be validated in the context of being used. So a macro just has to be taken as a given, without validation. But when a macro is used, it becomes concrete, and thus able to be analyzed. So as we step through and check things, we only log the name of locally defined macros. In assembly and routines, we expand macros and resolve parameters, logging the names we encounter.

This means that we have to recursively expand macros from the library as well.