The benefit of having a “byte” level encoding for source code is that the file sizes can potentially be smaller… though with the amount of 256bit hashes involved, that might not end up being true. If there is a high degree of reuse of hashes, it will probably be good, but if there are a lot if imports used only once, then probably not. Also in the source code, we probably want some kind of signifier of the hashes of symbols contained in the file, perhaps in a header that also contains import information. Another thing to worry about with source code is that you’ll want to keep names for reference, but that names across systems wont necessarily line up; we need the name for clarity of intention, and the hash for unambiguity. There will have to be “IDE-side” tooling to make sense of the name/hash alignment (and ultimately i think this will tie deeply into the cdb). But the source code itself will want to declare exactly its perspective of what names resolve to which hashes, which will override the local environment and will again need tooling to make it easy to update or resolve those names. All this to say, I think we’ll need some more symbols in the SourceCo subset to define name tables that get baked into the source module.

So I guess I need to have a set of “source code syntax symbols” that can be semantically analyzed/assembled/exported, and be transformed from/into text. Those source code symbols should be ByteCo, which encompasses all of the machine instructions as well as the additional set of SourceCo syntax symbols. By walking through this ByteCo, an assembler should be able to easily do the semantic analysis, assembly, or exporting.

Raw assembly can’t use LabelParam, ParameterDef, PathElement, RoutineImport, MacroImport, DefClose.Routine can’t use LabelParam, PaddingAbs, AnchorUseAbs, RoutineDef, MacroDef, ParameterDef, ImportDef, PathElement, RoutineImport, MacroImport.

Macro can’t use… I went on a tangent here realizing that if macros can use the entire byteco range, macros could be used to generate routines and all kinds of things. I looked into it a bit but decided that it goes too far outside the realm of simplicity that the language hopes to stick to, so maybe I’ll investigate again in the future. Macro can’t use RoutineDef, MacroDef, ImportDef, PathElement, RoutineImport, MacroImport.

Import can’t use anything except for Comment, NewLine, Indent, PathElement, RoutineImport, MacroImport.