Vitja Makarov, 14.12.2010 14:45: > 2010/12/14 Stefan Behnel: >> Stefan Behnel, 13.12.2010 06:37: >>> Vitja Makarov, 12.12.2010 20:23: >>>> What do you think about GeneratorWrapperNode? >>> >>> It seems ok. I'll give it a deeper look ASAP. >> >> Actually, after looking through it, I think it's an ugly hack. It tries to >> hide the fact that the DefNode does the wrong thing for the two faces of >> generators, and that the current implementation does not build a separate >> node at transform time that does the right thing instead. IMHO, two nodes >> are needed. A CFuncDefNode (or a subtype) that writes out the generator C >> function with the right signature and the original body, and the original >> DefNode (with the original signature) that has its body replaced by the >> necessary generator setup code. That's basically why the original CEP >> proposed to split the DefNode implementation *before* going for generators. >> Would have made this easier. > > Are you sure that CFuncDefNode for generator body is a good idea? > > Nested function and classes, lambda, generators are not supported > inside CFuncDefNode.
Hmm, right, that's a missing feature that could become a problem. Second try. Create a new subtype of DefNode that nails the signature to METH_O and additionally implements all the generator specific stuff, potentially through sensible hooks in DefNode's code generation. > Btw. It would be nice to make DefNode base for GeneratorNode, all the > generator creation stuff could be moved into generate_function_body() > and make generator body childern of GeneratorNode. I'm having trouble parsing the last part of this sentence, but it seems we are agreeing that a subtype would be a good idea. > I'm thinking of genexprs they are very similar to lambdas and could be > implemented reusing lambda stuff. Lambda is basically implemented as a little transform that creates a DefNode. I agree, it should be enough to just wrap generator expressions in a new DefNode and let the normal generator machinery do its work. However, note that this needs to interact with the EarlyReplaceBuiltinCalls transform in some way, which inlines generator expressions if possible. Looks like it's going to be tricky to arrange the related transformations according to the interdependencies, e.g. to the AnalyseDeclarationsTransform. I guess subtyping DefNode in two levels (DefNode<-GeneratorNode<-GeneratorExpressionNode) could be a step to fix this, as the inlining transform could then be changed to properly unpack that node instead of the current plain expression. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
