Hello,
Very interesting project, and looks like you’ve done some great work! I was curious and surprised to find that all of it was implemented in C#, including the Go parser.
I have actually toyed around with a very similar idea in the past, but my strategy was a little different. My approach was to use the built-in AST support in the core library to do the parsing for me, and to convert that into an intermediate form (my plan was just an XML representation of the go AST), and then do transformations on that AST to comparable form of C#.
I figured, by leveraging the built-in AST support in the native library, it would always be up-to-date by the Go team. Have you found any issues keeping the parser current as Go evolves?
I considered that as well - it just meant that I might be maintaining all or part of the code in Go, and unfortunately I am a better C# programmer than I am a Go programmer.
The ANTL4 grammar I am using has been pretty good, it works, but it is not perfect. Because of that, an intermediate XML/json/etc. representation like you mention parsed from Go’s built-in AST code might be a good approach, and certainly basically bug free since it’s maintained by Go itself.
That would make it possible to keep up with upcoming language changes (like generics) and I suspect the Go program would be fairly small and easy to maintain. One caveat would be that it would not be a deploy-once solution, that is, a compiled version of that tool for deployment would be platform specific - that said, may have to cross that bridge at some point regardless.
Ritchie