On Thu, 10 Jul 2008, Stefan Behnel wrote: > Hi, > > since there isn't currently a dedicated CEP page on generator support, I'm > wondering how they should be implemented.
Sorry, I see them as natural (and relatively straightforward) extensions of closures. > I kind of imagine that once closures are in place, it might be enough to put > all local variables of a generator function into a closure to keep their > state, and then put a label behind each yield statement and store the current > label in the closure whenever we return from the function. That would allow us > to just jump to the label on re-entry and continue the execution. This is exactly how I was planning on implementing them. > I do see that there might be a problem with deallocation of the closure, > though, as it's hard to tell when the generator is at an end. So an extended > way of doing it would be a transformation of the function into an extension > class, where local variables become class attributes. In order to avoid having > to split up the function body, it could be transformed into a single __next__ > method, and the execution could follow the goto-label scheme as described > above. That would even be independent of the closure support, although we > might want to avoid code duplication here. > > Would that make sense? > > Stefan Yes. This is in fact very much in line with how closures would be implemented--there would be an extension class that would hold the state (and garbage collection would happen when this object went out of scope, so no issues for generators or closures). The difference would be that closures get the function body put into the __call__ method and generators get the function body put into the __next__ method (with the jump table of course). One hitch that we ran into with closures (and the main reason IMHO that we didn't have time to finish them up like planned) is that variables are not bound at creation time, rather the scope is bound. Thus a function containing a closure needs to have special code as well as the inner function itself. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
