4 ms·
"A caller of a function in an imperative environment cannot assume anything about the scope of that function's access of mutable state within the program" This
by jfl 17y ago
"A caller of a function in an imperative environment cannot assume anything about the scope of that function's access of mutable state within the program"
This really doesn't make sense.
main() {
A a = new A();
f();
...
}
the caller main() can assume that "a" is not in scope of f().
Is it the robust refutation you need ?
The caller can further assume that the scope of f() is limited to the part of the state for which there is a path from a global variable or from one of its parameters (You can see the state as a graph. The nodes are the data and the links are the references) Therefore, this scope is not the whole state but a limited subset of the state.
Claiming otherwise is wrong and does not help to bring attention to what need to be improved : this subset is itself a superset of the part of the state that the function really need. We need new techniques to hide more state to the function, for example some kind dereferencement control ?
- KirinDave 17y agoI believe cemerick meant, "A caller of a function in an imperative environment cannot assume anything about the scope of that function's access of mutable state within the program without reading the entire program." If they verify it by perfectly understanding the underlying code, the of course that doesn't hold. But even in the code snippet you gave us, we really don't know if global state is being manipuated. For example, A could be handling global counters or referencing global variables (common example: stdin and stdout). And how do you know that a doesn't get manipulated by f()? You'd have to check! Perhaps A's constructor registers all A's it every creates and then f() marks all A's for protection from garbage collection? Really, we can't assume anything about the code snippet you gave us without verifying it. The code might be modular, it might be reasonably modular, or it might be a complete mess. This boundary of uncertainty is what functional programmers are railing against, and what you're defending.
- deleted 17y ago[deleted]
- jfl 17y agoWe have to agree to disagree. Peace.