6

I want to make a compiler for my own programming language. Popular backend choices seem to be C, Java, LLVM, JVM bytecode, .Net bytecode, gcc, assembly... Here, I am considering the possibility of Go as a backend.

Go is apparently a fast language, with garbage collection, and fast compile times. It is also portable and free (BSD-style licence). All those would make Go a good choice as a target of code generation, I think, maybe even better than the other options... So I am surprised I can't find anybody doing that already.

Would Go be a good choice for code generation? Can you point at existing projects doing so, or explain why there are none? Or even better, do you have experience with using the Go language as a backend? Are there any downside I am unaware of?

(I'm specifically interested in Go here. Don't just point at alternative backend options, there are questions answering that already.)

Community
  • 1
  • 1
Eldritch Conundrum
  • 8,452
  • 6
  • 42
  • 50
  • One interesting thing about using Go as a backend is that the standard library has packages for manipulating Go abstract syntax trees. So one option would be for you to build the AST of your output program in memory, and then convert it to text. – andybalholm Aug 18 '12 at 19:20
  • Go can be a backend for your language in the same way that C was a backend for C front. – Dave Cheney Aug 22 '12 at 00:23

3 Answers3

6
  • I'm not aware of any language project using Go as a back-end.
  • Go is not designed to be a compiler back-end and or an IR.
  • Go is low level enough (bit like C except for e.g. the GC) to IMO be usable as a back-end for some languages/class of languages with semantics similar/comparable/close to what Go offers.
  • Would love to know more about the language you're designing ;-)
zzzz
  • 87,403
  • 16
  • 175
  • 139
  • 2
    FWIW: #1 may be partially due to being quite young and not terribly mature (until the 1.0 release *at least*). #2 is also true for C, and JavaScript, and C++, and probably a few other languages used as backend for *something*. –  Aug 18 '12 at 16:54
0

There is this project called GoGo which is described to be a compiler written in Go and assembly for a subset of Go. Basically like a stripped down version of Go. I think you could start by modifying it to parse your own language.

I also remember a scripting-language-like subset of Go with its own compiler. I thought it was called GoScript but it seems like there are at least 3 different project with that same name so I wasn't able to find it.

I'd say do it and share your experience. Rather than a backend though, Go is going to be your intermediate language. At least that's what I think you want to do.

Cheers!

thwd
  • 23,956
  • 8
  • 74
  • 108
  • You appear to mix things up. OP is talking about a compiler, which may be written in *any* language and use any set of intermediate representations (even none at all), which generates go code, period. –  Aug 18 '12 at 17:54
  • Yes I did understand that part. The compilers in the examples I provided just so happen to also be written in Go. – thwd Aug 18 '12 at 19:58
  • At least one of your examples, GoGo, compiles go to something entirely else (unless they are terrible at writing readmes and their code is intentionally misleading). I can't judge the other one. And then there's your second-to-last sentence which is at odds with my observation about IRs. –  Aug 18 '12 at 20:33
  • you're right, I did mix things up to some extent. still I'll leave the answer - maybe it'll help someone in the future. – thwd Aug 18 '12 at 23:05
-1

If you will use Go as backend for your language then your language will be very similar to Go.

You will be able to implement

  • go routines
  • go channels
  • GC

You will no have

  • threads

Go is very good language. I do not see what you can add to make a better language over Go.

Max
  • 6,286
  • 5
  • 44
  • 86
  • 1
    Go is not Virtual Machine. Go generates native code. Virtual Machines are not better or worst then native code apps. – Max Aug 18 '12 at 11:15
  • If he will implement new language and use Go as backend then threads would be unavailable to him without using native C that is out of topic of question. – Max Aug 18 '12 at 11:18
  • A language that simply translates to Go, will have access to every single aspect of Go itself. I do not see how threads would be any different. The limits of what his language can do is entirely up to how much he decides to implement. – jimt Aug 18 '12 at 13:37
  • Thread t1 = new Thread(); is impossible in Go. So it would be impossible in language that will build over Go. Internally app may create threads But new language will have to use goroutines only. Gorotines are not threads. – Max Aug 18 '12 at 16:44
  • 5
    @Max: Not true. You can explicitly create a thread of execution in Go with [LockOSThread](http://golang.org/pkg/runtime/#LockOSThread). – zzzz Aug 18 '12 at 18:37
  • I was not aware of LockOSThread(). Does it make sense to create language that will use Go as backend and will provide Thread API with go func() { LockOSThread() ..... } (). I think if you have C, C++, Pascal as backend then you can implement one set of features. If you have Java then your language has GC if you use Go as backend you get goroutines and no threads and GC. – Max Aug 19 '12 at 10:01