On Mar 9, 2008, at 4:23 AM, Dag Sverre Seljebotn wrote: >> 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.
Fortunately for us, the parse tree follows the python grammar very closely, which is pretty static. This (plus a bit of extras like coercion and type declarations) is very close to what we would like to expose. The most brittle part is making new nodes (e.g. one has to know exactly all the right attributes). > 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. The full range of numpy indexing and slicing would probably be hard to implement in macros alone. > 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. One can keep in mind that our output is being passed to a C/C++ compiler, which are typically pretty good at eliminating many compile- time resolvable expressions and inlining functions. Our job is to write code that makes it easy for the C compiler to do so. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
