Open Technologicat opened 2 years ago
Turns out this is not as straightforward as initially envisioned. 2c7477c implements propagation of the scope of variable definitions from the parent scope into the continuation, recursively. But:
call_cc
) must shadow the same names from the parent scope, if they happen to exist there.with continuations
block is inside a function or not. This has implications to call_cc
invoked from the top level of the block: should the variables from the parent scope be declared nonlocal
or global
?So it may be better to abandon the experiment, and just document that introducing a continuation introduces a scope boundary. This is how it has always worked up to 0.15.1, though the fact was never documented. The behavior is no worse than how, in standard Python, comprehensions and generator expressions introduce a scope boundary.
The code of the experiment itself is sufficiently nontrivial to be worth keeping as a commented-out section, with a "don't do this, it's a bad idea" (for the above reasons) warning.
Thought about it a while; yes, let's abandon the experiment.
Thus, we need to update the documentation, particularly the section on continuations in doc/macros.md
.
There are updated examples in unpythonic.syntax.tests.test_conts
. As of f772df4, see near the end of the file.
Currently, if you assign to a local variable in a continuation, this always creates a new name local to the continuation.
If the parent function whose continuation it is has a local variable with the same name, the standard Python semantics is to update (overwrite) that name - because looking at the unexpanded user source code, we are still inside the same function.
In actuality, we of course are not. The continuation is a closure defined inside the parent function, thus causing this bug.
This is particularly insidious because in the user code, there is no hint of another scope being introduced. For least surprise, we should maintain the illusion that the standard scoping rules apply to the unexpanded source code.
To fix this, we should be able to just
nonlocal
any local variables of the parent function when we generate the code for the continuation closure.For where and how to do this, see the comment in the function
split_at_callcc
, inunpythonic/syntax/tailtools.py
.