> Presume the existence of a compiler that can compile Zig.
I just mean that the original WASM blob needed a working Zig compiler to produce it. But you can just assume it fell from the heavens. Now that it exists, you no longer need a Zig compiler binary in order to build a Zig compiler.
One way to think of it is that this allows the automatic creation of "stage 1" compilers from Zig compiler source. "Stage 1" was Zig's term for the original written-in-C++ Zig compiler, but I'm just using it to mean "A Zig compiler that does not need Zig".
To give a concrete example - say you want to add a new keyword gofast that makes all your loops go twice as fast. The first step would be to implement that in the written-in-Zig Zig compiler, without using the gofast keyword in your source. Once that's done, you compile your compiler. Then you update your compiler source code to use the new gofast keyword and recompile it again. But now you have a problem - how is someone going to build the new compiler from source if their build of the Zig compiler doesn't already support gofast? They would have to check out the commit (that their existing compiler supports) which adds gofast support but doesn't use it. Build that, then update and build again.
So, the alternative to that is that you update the "stage1" compiler which does not depend on Zig. But no one wants to update a crusty old C++ codebase. So instead, someone who has a gofast-enabled compiler compiles that source code down to WASI, and then anyone can bootstrap from there following the procedure we already discussed.
> Then you update your compiler source code to use the new gofast keyword and recompile it again. But now you have a problem - how is someone going to build the new compiler from source if their build of the Zig compiler doesn't already support gofast?
Thank you, this is what made me understand the core issue at hand here. I was confused as to why they needed to keep updating the "old" compiler once they had written the self-hosted one.
I just mean that the original WASM blob needed a working Zig compiler to produce it. But you can just assume it fell from the heavens. Now that it exists, you no longer need a Zig compiler binary in order to build a Zig compiler.
One way to think of it is that this allows the automatic creation of "stage 1" compilers from Zig compiler source. "Stage 1" was Zig's term for the original written-in-C++ Zig compiler, but I'm just using it to mean "A Zig compiler that does not need Zig".
To give a concrete example - say you want to add a new keyword gofast that makes all your loops go twice as fast. The first step would be to implement that in the written-in-Zig Zig compiler, without using the gofast keyword in your source. Once that's done, you compile your compiler. Then you update your compiler source code to use the new gofast keyword and recompile it again. But now you have a problem - how is someone going to build the new compiler from source if their build of the Zig compiler doesn't already support gofast? They would have to check out the commit (that their existing compiler supports) which adds gofast support but doesn't use it. Build that, then update and build again.
So, the alternative to that is that you update the "stage1" compiler which does not depend on Zig. But no one wants to update a crusty old C++ codebase. So instead, someone who has a gofast-enabled compiler compiles that source code down to WASI, and then anyone can bootstrap from there following the procedure we already discussed.