4 ms·
Continuations don't save "state", so his explanation is entirely right. Also, the mark() and return() operations (which are like goto) do save the environment,
by jules 19y ago
Continuations don't save "state", so his explanation is entirely right. Also, the mark() and return() operations (which are like goto) do save the environment, unlike gotos. That's why you can return() back into a procedure. You can't goto back into a procedure (well, in assembly you can but your variables will be gone).
- SwellJoe 19y agoEnvironment is not state? I'm afraid we have different definitions of state, then.
- jules 19y agoState genererally means the state of mutable things. Invoking a continuation will not reset the things you mutated, it will only reset the variables to their memory locations (in fact it does not "reset", the variables are still there). It's the same as with a closure: (let ((x 2)) (let ((closure (lambda () (print x)))) (set! x 4) (closure))) ; prints 4 not 2 The closure doesn't remember the old value of x, it just remembers the memory location.
- SwellJoe 19y agoI never said anything about resetting variables, and in fact, I emphatically mentioned copying the stack by way of clarification. I'm surprised you would misinterpret me to be saying anything about resetting variables. I'll try to refrain from using "state" in the future, when speaking to someone that could be from a functional programming background, since it seems to be so easy to misinterpret as "variables". I wasn't aware anyone used the term "state" to mean "variables", but I come from a C-derived lineage, and may have missed that memo. I'll also try to refrain from commenting in language weenie threads. It's not my forte.