Go compiler plugins?

<p>inb4: it&#39;s an x-post from &#34;Go Forum&#34;, <a href="https://forum.golangbridge.org/t/1143" rel="nofollow">https://forum.golangbridge.org/t/1143</a></p> <p>Ayyo,</p> <p>Seems like some of us might be interested in some 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&#39;t really change anything: Go team made it clear—language is stable.</p> <p>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 and parsing stage, modify ASTs.</p> <p>Related go-nuts thread: <a href="https://groups.google.com/forum/#!topic/golang-nuts/Hvua_aHSuK8" rel="nofollow">https://groups.google.com/forum/#!topic/golang-nuts/Hvua_aHSuK8</a></p> <hr/>**评论：**<br/><br/>calebdoxsey: <pre><p>I don&#39;t think its necessary. You can do the rewriting yourself as a separate program and then hand it off. </p> <p>Basically what I mean is you should un-invert the dependency. Rather than having the Go tool host a plugin, use the Go tool as a plugin for your own tool. (there are already tools that do this... for example the code coverage tool, gofmt, goimports, github.com/mailgun/godebug, etc...)</p> <p>Now what would be useful is a utility library that makes this easier to do.</p></pre>tucnak: <pre><p>You might have got me wrong. I do not suggest to build a plug-in infrastructure for tool-like things. Tools, e.g. go-generated, are capable of generating code or even re-writing it to some degree, but this has nothing to do with language itself. E.g. you can&#39;t add generics this way.</p></pre>xsolarwindx: <pre><p>Well actually you can write generics this way. It&#39;s not ideal but it&#39;s possible. You can do it the same way C++ does; convert templates to concrete implementations before compiling. I came up with a mechanism for this via go generate about a week ago. Been sitting as a stack of papers on my desk until I get a chance to prototype it.</p></pre>tucnak: <pre><p>Looking forward to take a look</p></pre>calebdoxsey: <pre><p>Sure you could. Fork the Go parser and lexer, then make your own generator that generates Go code, then hand off the generated code to the Go compiler.</p> <p>Adding generics would be a large change to the language - all the way down to the lexer. The whole toolchain would have to be updated. I think making it flexible enough to allow for this level of customization would mean it&#39;s no longer a Go compiler, but something more akin to GCC.</p></pre>jerf: <pre><p>To amplify on the other two replies that already exist, it is sufficient to use code generation to implement <em>anything you like</em>. Do you want to take a regex and convert it directly into Go code, rather than running through an interpreter? You can do that. You can literally do anything; you&#39;d be writing a compiler that targets Go.</p> <p>On the flip side, if you want to modify the language with something as deep as generics, you&#39;re probably better off simply forking Go. The reason being is that any compiler plugin technology deep enough to permit that is either A: just the aforementioned code generation in disguise anyhow or B: a massive overhaul to the compiler to permit such a deep level of modification that nobody is ever going to do. That specialized to something like &#34;generics&#34;, because as others point out, this would have to go in very, very deep. Far, far deeper than, say, merely implementing a new operator, which at least conceivably could be done as a plugin.</p> <p>And there&#39;s not much virtue to doing generics as a plugin anyhow... there&#39;s essentially 0 chance that a change as deep as generics and any other similarly extreme change would ever just &#34;go together&#34; through a plugin interface. It can&#39;t bring much benefit to Go.</p></pre>Ainar-G: <pre><p>Please no. Go has a simple and straightforward build process. &#34;go get example.com/foo&#34; should not turn into &#34;download the source code, download fifteen compiler plug-ins of these exact versions using this package manager, build them all in <em>this exact order</em>, install pip to install and run this Python script that calls a bash script that generates twelve makefiles and a LISP-based configuration file; oh, and make sure that libc is at this exact version that was installed on my Ubuntu when I first started the project&#34;.</p> <p>You might think I&#39;m exaggerating, but I&#39;ve worked with people whose build procedures in their C/ObjC/Ruby projects are about that level of complexity. I don&#39;t want any of that in Go, no matter how many lines of code those plug-ins will &#34;save&#34; me.</p></pre>tucnak: <pre><p><code>Go get</code> automatically fetches all required dependenices. It could fetch needed plug-ins as well (config file? action comments, like go:generate?), can&#39;t really see an issue here. On the other hand, your frustrations are fairly reasonable and I somewhat agree with your concerns (I came from the world of Qt/KDE, hate dependencies so much).</p></pre>