On Thu, Aug 5, 2010 at 10:13 AM, Carl Witty <[email protected]> wrote: > On Thu, Aug 5, 2010 at 1:27 AM, Robert Bradshaw > <[email protected]> wrote: >> +1 The transform could go through and replace any nodes that need >> special casing with special dot_net versions (that only need to know >> how to generate their code). This would keep things nice and modular. >> (The real question is how much code could be shared between the >> CPython bindings and the IronPython ones--the raw C code generation >> would probably be virtually identical.) > > I do like this idea. > > My tentative plan for merging the existing backend and the C++/CLI > backend back together is to move most of the C code fragments from > Nodes.py/ExprNodes.py into more methods on Code.py's CCodeWriter. > Then I would split the generic parts of CCodeWriter into a new base > class BaseCodeWriter, and add a new subclass CPPCLICodeWriter. Then > (hopefully) a single conditional in ModuleNode.generate_c_code, where > it creates the rootwriter object, could handle most of the differences > between the backends.
That sounds like a very good move in the long run. > For nodes where the code generation difference > is too large to be reasonably hidden in Code.py, your transform sounds > like a reasonable way to avoid "if dotnet:". > >> On this note, it would be cool if, eventually, Jython could be >> supported through similar mechanisms. > > That would be very cool. (I don't know anything about Jython > internals or the JVM foreign function interface, so I don't know how > hard it would be.) I don't know either, but the very act of supporting any other backend should shed light on this, even if the technical details are different. On Thu, Aug 5, 2010 at 10:32 AM, Carl Witty <[email protected]> wrote: > On Thu, Aug 5, 2010 at 3:56 AM, Robert Bradshaw > <[email protected]> wrote: >> My one concerns is if (taken to the extreem) having a visitor that >> knows how to generate code for every type (and the requisite >> internals) is preferable to encapsulating this knowledge on a >> node-by-node basis. Perhaps. > > Ah yes... the perennial style debate: if you have a bunch of data > types, and a bunch of operations on those types, is it better to group > the code by type, or by operation? (And of course there's no "right" > answer to such a generic question.) > > AFAIK, other compilers (like gcc and LLVM) group code by operation -- > I think they would typically have a source file for each compiler > pass, for example. On the other hand, Cython probably has more node > types (and semantically richer node types), and fewer operations, than > those compilers, so the right answer for them isn't necessarily right > for Cython... Yes, it's far from clear. If we're moving this direction long-term, it may be possible to use transforms to reduce things to a smaller subset of simpler node types earlier on. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
