On 26 January 2012 18:53, Stefan Behnel <[email protected]> wrote: > mark florisson, 26.01.2012 16:20: >> On 26 January 2012 06:39, Vitja Makarov wrote: >>> 2012/1/25 Stefan Behnel: >>>> Back to the old idea of separating the type analysis into 1) a basic >>>> typing, inference and entry creation step and 2) a proper type analysis, >>>> coercion, etc. step. >>>> >>> >>> Yeah! I think the issue must be fixed before release. We can start >>> moving slowly in this direction and split >>> CascadedAssignmentNode.analyse_types into parts: >>> - normal analyse_types()/expressions() >>> - create clone nodes at some late stage >> >> At what stage would the stage 2) proper type analysis take place? > > After the structural optimisation phase and before any optimisations or > other transforms that require complete type information but do not change > types anymore. I don't see it being moved to the end of the pipeline, the > results will be needed way before that. Even some optimisations may not be > possible without complete type analysis. > > >> Basically nodes may be replaced at any point, and I'm not sure you >> want to wait until just before code generation to do the coercions >> (e.g. GILCheck won't catch coercions to object, although assignment >> nodes seem to check manually). > > There's a large grey area in between. It'll need some refactoring and > rebalancing, just as before. But it should be easier than it is now because > the grey area will have more anchors in it. >
That's nice. It wouldn't solve the problem at hand though, and I think nothing can unless it will be at the very end of the pipeline. >> I think this problem can trivially be solved by creating a ProxyNode >> that should never be replaced by any transform, but it's argument may >> be replaced. So you wrap self.rhs in a ProxyNode and use that to >> create your CloneNodes. > > I can't see what a ProxyNode would do that a CloneNode shouldn't do anyway. It wouldn't be a replacement, merely an addition (an extra indirection). > Stefan > _______________________________________________ > cython-devel mailing list > [email protected] > http://mail.python.org/mailman/listinfo/cython-devel _______________________________________________ cython-devel mailing list [email protected] http://mail.python.org/mailman/listinfo/cython-devel
