[ Eric S. Raymond]
> ...
> I want this feature [generators] a lot. Guido has agreed in principle
> that we ought to have generators, but there is not yet a well-defined
> path forward to them. Stackless may be the most promising route.
Actually, if we had a PEP <wink>, it would have recorded for all time that
Guido gave a detailed description of how to implement generators with minor
changes to the current code. It would also record that Steven Majewski had
already done so some 5 or 6 years ago. IMO, the real reason we don't have
generators already is that they keep getting hijacked by continuations
(indeed, Steven gave up on his patches as soon as he realized he couldn't
extend his approach to continuations).
> I was going to explain coroutines separately, but I realized while
> writing this that the semantics of "yield" proposed above actually
> gives full coroutining.
Well, the Icon semantics for "suspend"-- which are sufficient for Icon's
generators --are not sufficient for Icon's coroutines. It's for that very
reason that Icon supports generators on all platforms (including JCon, their
moral equivalent of JPython), but supports coroutines only on platforms that
have the magical blob of platform-dependent machine-language cruft needed to
trick out the C stack at coroutine context switches (excepting JCon, where
coroutines are implemented as Java threads).
Coroutines are plain harder. Generators are just semi-coroutines
(suspend/yield *always* return "to the caller", and that makes life 100x
easier in a conventional eval loop like Python's -- it's still "stack-like",
and the only novel thing needed is a way to resume a suspended frame but
still in call-like fashion).
and-if-we-had-a-pep-every-word-of-this-reply-would-have-been-
in-it-too<wink>-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