3 ms·
Right, I completely forgot about the "stackness" of scope on the implementation side. Sides, actually, because both compile time and run time tend to be stacks.
by usrusr 4y ago
Right, I completely forgot about the "stackness" of scope on the implementation side. Sides, actually, because both compile time and run time tend to be stacks. If course they'd still be stacks, just with an unavailable marker attached to the "undeclared".
Fortunately, these days languages that are imperative at their core pick up "functional spillover" like that kotlin let seem to solve that nuisance-grade problem of a dangling `foo` temp just fine.
(the kotlin let is basically a list transform applied to a single instance, without all the pointless ceremony of wrapping as an Optional. I wanted to like scala more than kotlin, but I've come to respect kotlin a lot, for striking a balance between "language designer high" and the pragmatic mundane that must never be allowed full reign or else we get another groovy)
- a1369209993 4y ago> Sides, actually, because both compile time and run time tend to be stacks. Actually, runtime does not use a stack in the relevant sense (on non-toy compilers anyway). It allocates a stack frame on the call stack on a per-function basis, with possibly some other bits to handle variable-length arrays, but the actual local variables are allocated inside the stack frame in mostly the same way they're allocated in registers (but with less spilling). So the same 'undeclare'/register-coloring semantics apply.