Stefan Behnel wrote: > Hi, > > Dag Sverre Seljebotn wrote: > >> When it comes to FlattenInListTransform, I was thinking about something >> along the lines of an "StatAsExprNode", which would be sort of the >> inverse of ExprStatNode: It would contain a block which could contain >> "ReturnFromStatAsExprNodeNode" (though a better name is needed :-)) >> which would yield the value of the statement list, evaluated as an >> expression. >> > > I thought about this, too. The main problems with TempsBlockNode are that > it a) requires the type of a temp variable before hand (which is bad for > transforms that run before type analysis), and b) is a block statement, not > an expression. Making it an ExprNode and moving the current use into a > ExprStatNode would fix that. > BTW, I don't worry that much about transforms that run before analysis. All it means is that the constructs which they "transform away" must still keep implementations around for doing the analysis (which are already present anyway in most cases...)
Pure optimization transforms should always be done after analysis IMO, so I guess I consider FlattenInListTransform misplaced in the pipeline (though I don't know it well so I'm open for there being reasons I'm overlooking). Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
