> I feel that a strict separation between O(N) compiler output and O(1) intermediate processing artifacts [...]
I don't follow. He has just said that although the size of the arena is finite, the input and output are unbounded, and the compiler does its work by processing "a sequence of chunks" (i.e. those things that will fit into the finitely sized arena). That's not "O(1) intermediate processing artifacts". It's still O(n).
> [...] can clarify compiler’s architecture, and I won’t be too surprised if O(1) processing in compilers would lead to simpler code
This doesn't seem like an intuitive conclusion at all. There's more recordkeeping needed now, and more machinery in need of being implemented. One should expect that this scheme would make for things that are neither simple nor easy.
We haven't even gotten around to addressing how "statically allocating" a fixed size arena that your program necessarily subdivides into pieces (before moving onto the next chunk of input and doing the same) is just "dynamic allocation with extra steps". (If the idea is just that it would be neat to write/control your own allocator, then fine, but... say that.)
Having said that, if this is really all just a roundabout way to get the Rust people to actually give a damn about memory use and sell the idea that "you really shouldn't require more than 4GB of memory just to bootstrap the compiler and/or build other medium-to-very-large programs," then hey that's great.
I don't follow. He has just said that although the size of the arena is finite, the input and output are unbounded, and the compiler does its work by processing "a sequence of chunks" (i.e. those things that will fit into the finitely sized arena). That's not "O(1) intermediate processing artifacts". It's still O(n).
> [...] can clarify compiler’s architecture, and I won’t be too surprised if O(1) processing in compilers would lead to simpler code
This doesn't seem like an intuitive conclusion at all. There's more recordkeeping needed now, and more machinery in need of being implemented. One should expect that this scheme would make for things that are neither simple nor easy.
https://www.infoq.com/presentations/Simple-Made-Easy/
We haven't even gotten around to addressing how "statically allocating" a fixed size arena that your program necessarily subdivides into pieces (before moving onto the next chunk of input and doing the same) is just "dynamic allocation with extra steps". (If the idea is just that it would be neat to write/control your own allocator, then fine, but... say that.)