Dag Sverre Seljebotn wrote: > Continuining the LISP thread... > >>> The problem is that the code that accesses the syntax tree has to be >>> written in Python and inserted into the compiler at launch time -- you >>> cannot analyse yourself. >> So, how hard would it be to provide a mechanism to do this in the same >> file? There's a large subset of use cases for Lisp's macros which need > > Heh, ok, starting to understand you. Well, I can think of a way to have > compile-time macro support in Cython that would make sense and be a > natural part of other optimizations, however that is *far* in the future.
As you say later on, this is just dreaming. But dreaming is fun. :) Actually, I think there's a version, completely separate from the transform code that started this thread, that might not be hard at all. The basic idea of Lisp macros is that: 1. Lisp makes it easy to manipulate lists, including lists of lists. 2. In Lisp, all code is represented as lists. 3. So, it's pretty easy to write code which produces Lisp code. Of course, Python/Cython programs aren't represented as lists. However, programs can be naturally represented as an abstract syntax tree. In fact, that's a standard representation inside a compiler. It follows naturally from how a language is structured: a block contains 1 or more statements, the statements contain expressions, which contain sub-expressions, etc. It's essentially a Document Object Model (DOM) for source code, which is already hierarchically structured. So it would be easy to come up with a representation of Python/Cython program using standard Python data types, where elements correspond 1-1 with the parts of a program. So that takes care of 2, and Python has lots of ways to work easily with lists as well as many other data structures, which takes care of 1. 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. > Python have for a long time allowed "run-time" macros, ie code generation, > of course (though perhaps not as powerful as LISP, and gives a slower > implementation): > > def make_adder(howmuch): > def adder(x): return x + howmuch > return adder > > add10_func = make_adder(10) > print add10_func(z) # prints the value of z+10 > > Now, adding two seperate (hard!) features to Cython: > 1) Supporting inner functions, ie closures, at all > 2) Automatically collapse function calls where one can know that the code > doesn't depend on anything that isn't known at compile time. As you say, this is significantly different from Lisp macros, and the compiler needs to be very clever to make it efficient. A basic "defmacro," as outlined above, should be easy to implement, and to implement efficiently. Just a thought, Martin _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
