lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Your example is counter intuitive: why does the last assert(foo==3) has to be true (the outer scope was modified by the double-inner  scope use of "unset": why does then foo=3 would not affect instead the middle scope and then throw an error on assert(foo==2)?
If that "assert(foo==2)" passes then the "unset foo" has no effect than just being equivalent to "local foo -- =nil" and then the last assertion assert(foo=3) should fail because foo is still equal to 1.
Your idea would create a security havoc where programs can unhide the protection layers to get access to internal variables being normally inacessessible to them.
The only safe behavior would be that "unset foo" is like "local foo" (so "unset" is not necessary at all) but still different from the assignment "foo=nil" which overrides the value of the same variable in scope (only the former value of that variable will be closed and garbage collected, but the scope does not change: that same variable continues to used in other references, notably in other function closures).
Alloing a program to control the scoping of outer varisables they did not declare themselves is a crazy and dangerous idea.

Le mer. 26 juin 2019 à 22:27, Soni "They/Them" L. <fakedme@gmail.com> a écrit :
okay so a while back I talked about this "unset foo" idea, that would
allow you to get through to shadowed names.

the example I gave was basically:

local foo = 1
do
   local foo = 2
   do
     unset foo
     foo = 3
   end
   assert(foo == 2)
end
assert(foo == 3)

(I don't remember the exact examples I gave but I like this one.)

anyway, nobody liked it back then and I don't expect anyone to like it now.

but since we're talking about __close and toclose and stuff, why not use
__unset instead? it's called when a variable is unset i.e. goes out of
scope. (as long as we don't get the ability to unset variables like I
proposed with non-linear lexical scoping, at least.)

it still doesn't solve the "what to name the <toclose>" problem, but,
I'd prefer __unset over __close, personally. (ideally we'd also have a
__set for when the value is assigned to one of those special variables,
but I digress.)