4 ms·

Even if we ignore ownership semantics for a moment, I find myself missing an explicit per-identifier end of scope ("undeclare") surprisingly often. The workarou

by usrusr 4y ago

Even if we ignore ownership semantics for a moment, I find myself missing an explicit per-identifier end of scope ("undeclare") surprisingly often. The workaround is anonymous blocks, at least if you're one of those who don't like chopping up code into countless single-use functions. But that forces you to do early declaration when aiming for overlapping scopes and I really don't see a reason for this limitation. I guess the main reason for the absence of "undeclare" in most languages is that features affecting only local scope are beneath most language designers?

a1369209993 4y ago
> I guess the main reason for the absence of "undeclare" in most languages is that features affecting only local scope are beneath most language designers? Actually it's because approximately every damn compiler framework or textbook assumes that local variables go into and out of scope in a stack/LIFO order. (So if you declare `foo` and then `bar`, `foo` can't go out of scope until `bar` does, even if `foo` was a random temporary and `bar` is needed for the entire rest of the function.) And all the algorithms for working with local variables bake in this assumption, so you have to redesign everything to get back the sane semantics you get for free in assembly. At least that's my experience with implementing proper local variable scoping; YMMV.
- 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.

by usrusr 4y ago

a1369209993 4y ago

> I guess the main reason for the absence of "undeclare" in most languages is that features affecting only local scope are beneath most language designers? Actually it's because approximately every damn compiler framework or textbook assumes that local variables go into and out of scope in a stack/LIFO order. (So if you declare `foo` and then `bar`, `foo` can't go out of scope until `bar` does, even if `foo` was a random temporary and `bar` is needed for the entire rest of the function.) And all the algorithms for working with local variables bake in this assumption, so you have to redesign everything to get back the sane semantics you get for free in assembly. At least that's my experience with implementing proper local variable scoping; YMMV.

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.