Greg Ewing wrote: > Dag Sverre Seljebotn wrote: >> The big refactoring you refer to is related to >> seperating the type analysis and type coercion phases > > I'm not sure whether you would gain much by doing this. > The place where you discover that a coercion is needed > is during type analysis, where you look at the types of > the operations, decide whether they're compatible, and > see whether they need to be converted to a common type, > etc. Also you work out what the result type will be and > annotate the node with it. > > To move the creation of coercion nodes into a separate > pass, you would have to leave an annotation on the node > saying that a coercion is needed. But if some phase > between then and doing the actual coercions rearranges > the parse tree, these annotations may no longer be > correct.
You're right, there's a problem even with annotations in this case. I'd just like to note that passing such annotations is common with transforms (as long as it is well-defined information that is added to the tree, keeping information in such annotations allow for easier seperate testing and concise documentation than if the state lives in temporary variables somewhere on the stack). > So you would have to disallow any other phases between > type analysis and coercion, or at least put some > restrictions on what they can do, such as not altering > the structure of the parse tree, or doing anything > else that could invalidate the calculated types. > > What sort of things were you intending to do in between > type analysis and coercion? Could they still be done under > these restrictions? Thanks, this is going to be very helpful to me and will make me able to express myself much clearer. My main problem was simply that for variables for which the type is explicitly given, as well as , the type is not resolved. I.e I believe there should be two steps, with a possibility for transforms in-between: a) Mark up all the types of declared variables. b) Expressions have their type resolved (which might involve coercions). Alternatively, one could seperate between easy, nonoverloaded behaviour (a) + calling functions, dereferencing pointers etc.) and overloaded behaviour (the rest, especially binary operators). Though this distinction seems more arbitrary. The goal was simply to have transforms that was able to act based on variable types; mostly in order to implement assumptions (http://wiki.cython.org/enhancements/assumptions). For instance, cdef MyArray[len=10] arr = ... cdef int last_idx = arr.len - 1 Here, "arr.len" gets a different value, and potentially different type, because of behaviour explicitly attached to the arr variable (not the "arr" expression). I'm still digesting your input though. It made me rethink some cases (they could be done independt of coercions, but then I realized that this was dependent on the combination of type inference and overloaded coercion operators not becoming a reality. Not such a big danger (in fact, I'll have to think on whether such a combination is internally inconsistent, I have a hunch it is) but I'd like to revalidate my assumptions at this point. Long story...) The rest of your email was very interesting too but I'll mail this now or I won't ever finish it, might answer the rest later. (But yes, I did not think about memory usage too much, and I'll get back to the 150 lines closures implementation, either to prove it or admit that I was wrong :-) ). Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
