About the "whatever is d[k]" in five minutes comment: If I created an explict closure like: `thunk = lambda: d[k]` and then mutated `d` before evaluating the closure you would have the same issue. I don't think it is that confusing. If you need to know what `d[k]` evaluates to right now then the order of evaluation is part of the correctness of your program and you need to sequence execution such that `d` is evaluated before creating that closure. On Fri, Feb 17, 2017 at 4:17 PM, Joseph Jevnik <joejev@gmail.com> wrote:
There is no existing code that uses delayed execution so we don't need to worry about breaking it. I think it would be much easier to reason about if forcing an expression was always explicit. I am not sure what you mean with the second case; why are you delaying a function if you care about the observable side-effect?
On Fri, Feb 17, 2017 at 4:14 PM, Ed Kellett <edk141@gmail.com> wrote:
On Fri, 17 Feb 2017 at 19:38 Joseph Jevnik <joejev@gmail.com> wrote:
Delayed execution and respecting mutable semantics seems like a nightmare. For most indexers we assume hashability which implies immutability, why can't we also do that here? Also, why do we need to evaluate callables eagerly?
Respecting mutability: we just have to always, we don't know if a delayed thing is hashable until we evaluate it. This thing has implications for existing code (since delayed objects can get anywhere) so it should be careful not to do anything too unpredictable, and I think d[k] meaning "whatever is in d[k] in five minutes' time" is unpredictable. One can always delay: d[k] if it's wanted.
Evaluate calls: because if you don't, there's no way to say "strictly evaluate x() for its side effects".