Of all of the Mill subjects, the pointer kludge to support fork (itself a kludge, yes) seems to me to be the biggest offender of the "sufficiently smart compile

Of all of the Mill subjects, the pointer kludge to support fork (itself a kludge, yes) seems to me to be the biggest offender of the "sufficiently smart compiler" red flag. I just have a sinking feeling about hoping a compiler can correctly identify and track all pointers to know how to flag them. The "pointer is a native-word-sized int" assumption may be so ingrained -- from compilers to stdlibs to the wide variety and age of programs -- that it will be nigh impossible to rid existing codebases of it completely. But I'm not a compiler guy (or hardware, or assembly, or C for that matter) so I could be quite mistaken. Perhaps it's enough to fix the compiler and make it capable of emitting warnings/errors when it detects a violation. As far as the talk itself goes, I'm a little sad that there was so little new information though I understand that we're quite deep in the technical details and there's a lot of prerequisite background that you can't reasonably expect from a random tech audience. If there are more than a few more talks you might need to reevaluate this method altogether and use a different format. I'm very glad that you've decided to change the wording to refer to it as an "SSA machine" as opposed to "belt". I think many more people are familiar with SSA or can be convinced that it works ("your current compiler uses it right now" probably helps) by describing it as "SSA where you can only reference the last N results" as opposed to building a whole model based on a "conceptual giant shift register" from before. I've been following the Mill talks since the first few videos and recently I wonder if even the asm programming model should be writing raw SSA instead of belt numbers, especially since genasm assumes an infinite belt anyways.