> > So if we could introduce the concept of a special kind of function, > which is run at compile time, and which takes the (unevaluated) parse > trees of its arguments, instead of the runtime values of them, we > could probably have something equivalent to Lisp macros. A macro > would be a lot like transforming an XML DOM into another DOM, except > instead of XML it's a parse tree. > > A basic "defmacro," as outlined above, should be easy to implement, > and to implement efficiently.
Hmm. I believe you are right. A problem though is that the parse tree is currently very subject to change all the time as Cython develops, so one would need to insert an "API" tree instead of a raw export I think, which would make it a bit more work. But not very much. This is certainly one perspective to take in the development of (perhaps parts of) NumPy support and so on, it could be based on macros. I don't think I'd vote for such an approach but the idea certainly has some merits and it might be worth it to pursue it a bit. I know that some kind of compile-time execution of code would be nice to have (proof: I once came across a mathematical C++ library that did extensive compile-time optimization of your code. How did they write it? Using C++ templates for compile-time meta-programming. Ugh. Imagine finding the square root of a number at compile time using C++ templates...) For the usecases I can think of the "compile-time evaluation of closures" would be more user-friendly, but of course one approach doesn't rule out doing the other later. Write a proposal in http://wiki.cython.org/enhancements perhaps? -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
