On 06/12/2021 09:44, Stephen J. Turnbull wrote:
Rob Cliffe via Python-ideas writes:
Nobody has attempted (or at least completed) a PEP, never mind an implementation, of a "generalized deferred object/type", in the last N years or decades.
Haskell anything. Ruby blocks. Closer to home, properties and closures.
So I don't think the object part is that hard, it's the syntax and semantics that's devilish. The evaluation syntax doesn't seem hard: you just reference the identifier the object is bound to. The creation syntax, though, probably needs to be concise, maybe even familiar, as Chris's proposal is.
For the semantics, just in the case of defining an alternative to PEP 671, consider: if you just stuff a generalized deferred expression object into a formal argument's default, you still have to solve the problems that Chris's proposal does: where do you get the appropriate namespace to extract variable values from? and when do you do it? I do admire the elegance of Chris's solution to those questions, but if I were to fit a generalized deferred into that role, I might not adopt the "evaluate deferreds just before entering the function body proper" strategy.
And then there's the question of whether referencing the deferred "collapses the waveform" into an object and binds it to the original identifier (as in Chris's proposal, but for more general contexts), or whether the deferred gets reevaluated each time in the current context (as Ruby blocks and Python properties usually do).
I think you're making my point. You're saying that the object part isn't that hard, but other parts of it are. Which overall means that it is a hard problem. And there seems to be no likelihood of anyone tackling it soon. (If anyone is working on it now, or planning to soon, please correct me.) I can't see the point of rejecting something that provides a tangible benefit, now, because some fictitious vapourware *might*, one day, provide another way of doing it. Best wishes Rob Cliffe