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.
Right, we might want to have two parse trees: an initial one for macros, that matches user concepts 1:1 with a stable API, which is then transformed into a second one, used internally by the compiler. Of course, I expect the translation from the first to the second to be just a few tweaks here and there, and so would be somewhat trivial. Maybe even a no-op. > 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 think it's too early to recommend for or against it, but I think it's worth exploring. > 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...) Someone at work mentioned that, after programming in Lisp for many years, they had to learn their first purely functional language: C++ template meta-programming. It's Turing complete, but you don't even have loops, you have to implement them using recursion. > 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? Will do. Best, Martin _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
