On Thu, Aug 5, 2010 at 2:39 AM, Dag Sverre Seljebotn <[email protected]> wrote: > Robert Bradshaw wrote: >> On Thu, Aug 5, 2010 at 12:08 AM, Dag Sverre Seljebotn >> <[email protected]> wrote: >> >>> On 08/05/2010 06:01 AM, Carl Witty wrote: >>> >>>> I'm working with Enthought on a branch of Cython to target .NET for >>>> IronPython. I'm maintaining a repository at >>>> http://bitbucket.org/cwitty/cython-for-ironpython (I just started >>>> writing code, so there's not much interesting there yet). >>>> >>>> >>> Great, I think this is fantastic news. >>> >> >> I'm excited about this too. >> >> >>>> I'm hopeful that eventually this code will be merged back into Cython; >>>> I don't want to fork Cython. >>>> >>>> >>> I hope this stays in Cython as well. >>> >>>> I'm starting by essentially duplicating all of the generate_* methods >>>> into generate_dotnet_* methods, and modifying the duplicated methods >>>> to generate C++/CLI code. My hope is that once I have a working >>>> >>>> >>> Ah, this is very interesting -- when I've spoken with Enthought on the >>> matter we've largely ignored C++ for this and were talking about a C# >>> backend. >>> >>>> compiler, I can refactor to merge most of the methods back together >>>> (eliminating the duplicate code) while still not being very intrusive >>>> to the original codebase. >>>> >>>> >>> Have you considered writing a transform instead of adding more methods >>> to the nodes? E.g. something like Cython/CodeWriter.py for the .NET >>> backend? That would be even less intrusive...ideally, one would just >>> configure the pipeline differently depending on what the backend is. >>> >> >> +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 was actually thinking that one had the "transform" (or rather "sink") > just emit/serialize code directly when visiting a node. The "return > value" could either be string fragments, or if that is too inefficient, > nothing at all. > > def visit_BinopNode(self, node): > # Very naive, I know things are more complicated... > return '%s %s %s' % (self.visit(node.operand1), node.operator, > self.visit(node.operand2)) > > def visit_FuncNode(self, node): > # Here we would return a StringIOTree instead (see > Cython/StringIOTree.py), > # for efficiency. > > or, perhaps just: > > def visit_BinopNode(self, node): > self.visit(node.operand1) > self.put(node.operator) > self.visit(node.operand2) > > So generate_... would never be called, on *any* node, when doing .NET > output. > > One could deal with shared CPython/.NET code by creating a superclass: > > class CLikeCodeGenerator: > # pull out stuff that is common between CPython and .NET here > > class DotNetCodeGenerator(CLikeCodeGenerator): > # .NET-specific nodes handled here > > class CPythonCodeGenerator(CLikeCodeGenerator): > def visit_Node(self, node): > # for now, just call generate_... if the node wasn't handled > # by CLikeCodeGenerator > > > This makes it easy to plug in Java as well without making Nodes.py and > ExprNodes.py even larger and more tangled and more full of conditionals...
Ah, yes, I remember discussing this before. If that could be pulled off, it would be nice and clean. The fact that memory management is handled for you (I think) makes things much simpler. 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. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
