[Thomas Wouters] > ... > There is no reason for 'yield' not to be an expression. "not" and > "and" and "lambda" and such are all expressions too, remember. But > making 'yield' a statement is a very good choice, in my eyes. What > should > > ((yield a) ** (yield b) and (yield c)) ^ (yield e) / yield f > > yield ? 'yield' is too similar to 'return' for it not to be a statement. If we had been able to think of an "obviously correct" way for yield to return a value, we would have -- but we didn't, so we didn't <wink>. The temptation is that it's very handy for a coroutine transfer to "act like" a function call from a transferor's POV: this gives a way for *its* resumer to communicate info back to it. I first saw this in Icon, and it was a huge and obvious improvement over Simula 67, wherein coroutines could communicate only via stuffing values in shared globals. Since PEP 255's "Simple Generators" are only semi-coroutines, the need isn't acute, but could still be handy at times. Anyway, Neil implemented *lots* of ideas that didn't survive: we all agreed to slice out features left and right until the Simple in "Simple Generators" earned its name. They're still fancier than Icon's and CLU's generators (because explicitly resumable even in the absence of magical control context) all the same. I'm curious to see how people use the "extra" power in practice, and can't predict which kinds of extensions would be truly useful. Until real life makes that clear(er), I'm inclinded to resist any change; in the meantime, we haven't precluded turning yield into an operator someday, neither extending its syntax as a statement. right-now-it's-the-simplest-thing-that-could-possibly-work-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4