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...
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
