Dag Sverre Seljebotn 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:
>
Actually, in the first pass, one could implement DotNetCodeGenerator
like this:
class DotNetCodeGenerator(CLikeCodeGenerator):
# Default fallback to CPython generation
def visit_Node(self, node):
node.generate_...(self.code)
def visit_ExprNode(self, node):
# Slightly different logic I believe...
node.generate_...(self.code)
# Any .NET specific stuff
def visit_FuncNode(self, node): ...
Dag Sverre
> 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
>
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
