[sbinet]

interesting, it's true having a toolbox for creating go interpreters would be much more powerful.

I am not sure I completely get what a compiler-as-a-service really is. could you expand please?

(wrt JITing, yes, we considered it and it's on our radar. we know some version of it worked at some point, at least at the proof-of-concept level: https://github.com/nelhage/gojit)

thanks for your input!

[zamalek]

I suppose CAAS[1] doesn't make much sense outside of the .Net community :). The idea is that you very aggressively break down the compiler into the core constituent parts.

A less Microsoft-centric project would be Clang. Clang is quite accessible and despite that it's not as loosely coupled as Roslyn (e.g. I don't think you can refactor using it), you can still solve some real problems with it (such as autocomplete and static analysis).

Basically, CAAS is the front-end equivalent of LLVM. You turn the whole compiler into a very tidy API: following from that it should be significantly simpler to create something such as the interpreter that you are aiming for.

[1]: http://www.infoworld.com/article/2621132/microsoft-net/micro...

[sbinet]

ah, didn't know about CAAS. of course LLVM/CLang was also on our radar. we are still pondering on whether we should target LLVM bitcode so we could easily build upon LLVM toolchain (and cross-pollinate with other LLVM-based interpreters. e.g. seamlessly interoperate with IJulia and CLing interpreters, sharing code and values at runtime thru LLVM.) to me, the main issue with LLVM is that it's a real pain to develop against, I know this for a fact having worked a little bit with CLing, the CLang-based C++ interpreter (the edit-compile-test cycle is that of a set of large C++ libraries, gophers tend to be spoiled in that department)

tangential: actually, you can refactor with the CLang libraries: http://llvm.org/releases/3.7.0/tools/clang/docs/LibTooling.h... (well, to some extent)