Go compiler plugins?

Technical Discussion
1

Ayyo,

Seems like some of us might be interested in different language changes, which are unlikely to happen, right? Some people miss generics, some think that //go:generate is done wrong, we can spend hours discussing this sort of stuff, but it won’t really change anything: Go team made it clear—language is stable.

I just thought about a possible workaround. Things would have been so much easier, if Go compiler had a plug-in infrastructure (like clang does, for example). We do have a compiler fully written in Go and dynamic runtime linking in 1.5 already, it seems to not be an issue. Plugins could do any operations on lexing, parsing stage, modify ASTs.

Related go-nuts thread: https://groups.google.com/forum/#!topic/golang-nuts/Hvua_aHSuK8

1 Like
2

There are no plans to add this, however as the source of the compiler is pure go, you have all the raw materials you need.

2 Likes
3

I would recommend using “go generate” for this type of thing. That way even people who don’t have that “plugin” will be able to compile your code.

After looking at Perl 6, I strongly support Go’s stance on this even more.

4

I don’t think this proposal actually addresses the underlying issue, why these language changes are not happening right now. To be absolutely clear: Everything that speaks against adding this stuff to go proper also speaks against adding it as a compiler plugin and then some.

go is designed to be a simple language. It is designed with strong readability in mind. It is designed to make it hard (though it doesn’t make it impossible) writing clever code that is not obvious to anyone reading it, no matter how unfamiliar they are with the code base. Throwing compiler plugins into the mix will completely destroy this. It is diametrically opposite to the design goals of go. It would make go to what C++ currently is: Less of a language than a build-your-own-language kit, where you essentially have to relearn the correct subset of language features used in a particular project.

If you think you know better than the go team in regards to some language features in if and how they should be added, do as /u/jerf suggested and fork go. Because your plan amounts to every “compiler plugin” being essentially a little incompatible fork of go and it is more honest (and fair towards people who like go’s simplicity) to make this fork official.

4 Likes
5

Go supports variable shadowing though -__-

6

You’ve posted about this before. Whilst it’s not great, some lack of clarity around variable scopes/shadowing doesn’t mean the language as a whole is not simple/readable.

7

If you want to extend the language, do you expect gofmt, goimports, oracle, go/parse and other citizens of the Go ecosystem to work with programs written in the extended language? It seems that most of the tools around Go would stop working

1 Like
8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.