The Transpilation Machinery really does need some reworking.

[revusky]

I'd like to bring your attention to this point in the current code. I rewrote the translateCodeBlock method there.

I mean, the way it was written (and there must be other cases of this) it really does give off a code smell, to put it mildly. The javaCodeBlock that is exposed to the template actually is an instance of org.congocc.parser.tree.CodeBlock. So, what you were doing is doing an implicit conversion of this to a string, and then instantiating a new parser instance to reparse it and...

Actually, I came across this because I inadvertently broke the code in my FreeMarker hacking, because the coercion of the code block variable into a string was broken for a while. (Basically the existing code worke because, if a Java method took a String parameter, it would coerce the parameter into a string, using the object's toString() method, and...) But anyway, then I looked at the code in question and was kind of shocked that it was getting flattened into a string and then reparsed into a tree, when it was a tree to start with! I mean, seriously, does that really make much sense?

Generally speaking, this code really does need to move more towards being a tree-to-tree transformation, rather than string-to-string. But, in partcular, the congocc.jar already contains all the classes for the Python and C# AST's. (This has been the case since early this year.) There are already all the nodes in org.congocc.parser.python.ast and org.congocc.parser.csharp.ast respectively. They are all empty classes, but you can inject functiionality into them by editing the files PythonInternal.ccc and CSharpInternal.ccc respectively.

Well, I mean to say, this proposed approach, reusing the generated AST for the Python and CSharp grammars is bound to result in a much more elegant and appealing solution. I'm quite sure of this. In particular, this humongous method can surely be refactored to use the built-in tree-walking Node.Visitor API that we have. And, in any case, this would result in more overall code reuse.

Well, if you want me to have a go at it to sort of show the way, I could do that, I guess. But I think you have the wherewithal to get going on it. And if you have any questions, by all means. I think the transpilation thing is fairly promising and I have speculated that we could even make a separate standalone tool out of it, but I think we need to get things on a somewhat more solid basis, if you see what I mean...