24 ms·
The problem isn't shadowing. The problem is capturing by reference. It's utterly confusing, because it means that all closures that you create in the same envir
by catnaroek 10y ago
The problem isn't shadowing. The problem is capturing by reference. It's utterly confusing, because it means that all closures that you create in the same environment share the same mutable state - delicious action at a distance!
Languages where closures capture by value (ML, Haskell) or where the programmer explicitly chooses between capturing by value and by reference (C++, Rust) are free of these complications.
- eternalban 10y agoThat terminal '}()' is there for a reason. https://play.golang.org/p/zyMbmJsnUz https://play.golang.org/p/zyMbmJsnUz // minor mod of donatj's example.
- catnaroek 10y agoThis is reminiscent of the common Python hack `lambda n=n: whatever`. Well, it's a hack.
- Peaker 10y agoHaskell doesn't necessarily capture by value or by reference since you cannot distinguish between the two when all values are immutable.
- catnaroek 10y agoWhen I say ”by value”, I mean the abstraction the programmer is exposed to, not the internal implementation detail. In a Haskell implementation, the environment may well be internally represented as a pointer, but the programmer doesn't need to worry about that. On the other hand, a Go, Python or Lisp programmer is constantly and painfully reminded of the difference between copying an object and pointing to a pre-existing object.
- Peaker 10y agoHaskell programmers do have to think about it as being by-reference if they want to understand the performance/memory-use due to sharing. But for correctness, yeah, you just don't have to think about it. So you don't think "by value" or "by reference", it just becomes something obvious that you don't need to think about.
- catnaroek 10y ago> Haskell programmers do have to think about it as being by-reference if they want to understand the performance/memory-use due to sharing. Oh, right.