>> In our Lisp, when we re-assign a name we’re going to delete the old association and create a new one. This gives the illusion that the thing assigned to that name has changed, and is mutable, but in fact we have deleted the old thing and assigned it a new thing.
> Please don’t do that. What would be the result of evaluating:
(let ((a 1))
(+ (let ((a 2)) a) a))
That is off the mark; that example doesn't re-assign anything; it is binding a shadowing instance of a.
Removing a binding and destructively creating a new one in the same environment is a viable strategy for implementing assignment, compared to mutating just the value part while keeping the same binding cell.
You can implement it so that the semantics is absolutely identical; the program simply cannot tell.
If you try to make it nondestructive somehow, then the program can tell; e.g. if you functionally rewrite the current environment to produce a new environment in which the variable is edited to the new value. then closures will reveal the trick. Previously captured closures keep seeing the old environment and old value (obviously inapplicable discussion to dynamic scope).
If a variable that has been captured by any number of closures is destructively assigned, all the closures must see the new value after the assignment, otherwise you have something other than assignment.
> Please don’t do that. What would be the result of evaluating:
That is off the mark; that example doesn't re-assign anything; it is binding a shadowing instance of a.Removing a binding and destructively creating a new one in the same environment is a viable strategy for implementing assignment, compared to mutating just the value part while keeping the same binding cell.
You can implement it so that the semantics is absolutely identical; the program simply cannot tell.
If you try to make it nondestructive somehow, then the program can tell; e.g. if you functionally rewrite the current environment to produce a new environment in which the variable is edited to the new value. then closures will reveal the trick. Previously captured closures keep seeing the old environment and old value (obviously inapplicable discussion to dynamic scope).
If a variable that has been captured by any number of closures is destructively assigned, all the closures must see the new value after the assignment, otherwise you have something other than assignment.