3 ms·
Immutable local state is (as you've observed in that example) harmless, but once you start mutating closed-over state, you've given up completely on referential
by lomnakkus 13y ago
Immutable local state is (as you've observed in that example) harmless, but once you start mutating closed-over state, you've given up completely on referential transparency[1] which gives you a lot of power when reasoning about what code does (and doesn't!) do.
[1] https://en.wikipedia.org/wiki/Referential_transparency_%28computer_science%29 https://en.wikipedia.org/wiki/Referential_transparency_%28co...
- davexunit 13y agoI think closed-over mutable state certainly has its place. For example, delay and force in Scheme. Mutable local state is used to memoize the result of the delayed procedure. Of course, it would be terrible for a large program to keep all of its state within a closure. You eliminate the benefits of live-coding from your REPL at that point since you can only directly affect the top-level environment.
- mercurial 13y agoCertainly, but you don't even need closures for this: def foo(): a = [] append_foo(a) return a def append_foo(a): a.append('foo') But then I wouldn't call this "local mutability", in the sense that you modify your list in a different part of the code. Not a problem in a trivial example like this, definitively an issue when the actual action performed is ten levels deep.