[mwsherman]

It’s interesting that it’s not mentioned. I might suspect it’ll be C, as otherwise they’d need to build a new C parser in Go to even get started. Why not use a mature one, and add the Go transformation?

Edit: to be more precise, they’d need to get the C syntax tree in some representation first. Then pass it over to a transformer. The latter could be in Go, but it seems foolhardy to reinvent the former.

[hrjet]

By the time I reached this post, the number of translation tiers managed to confuse me. To help others, here's a breakdown.

Notation: T[A,B] : Translates from A to B

The OP wants to develop T[C, Go]. The question is which language should T[C,Go] be written in?

Option #1: If T[C,Go] is written in C, then it can use an existing C parsing library to parse C and then emit Go. Here parsing will be easier, but emitting Go will be laborious to write in C (since C is very low level).

Option #2: If T[C,Go] is written in Go, then the parent claims that C parsing will have to be freshly developed in Go. This will be a pain but the Go emitting code will be easier to write in Go.

However, I think the problem with option #2 (parsing) can be avoided if one uses the parsing library that is assumed to be already available in C. Since Go can interface with C code[1], the parser need not be reinvented.

[1] : http://golang.org/cmd/cgo/

[lucian1900]

Even if written in C, generating source code is trivial compared to parsing. The translator doesn't have to output the prettiest code either, since there's gofmt/fix.

[amboar]

Clearly the sane route would be write T in C then once complete run T through T to emit a C to go translator in go.

[rsc]

The parser is the only part I've written so far. It took me an evening (Go has yacc).