Function compositions?

<p>As I understand it, Go is a functional language or has functional language features?</p> <p>So how does something like this from Lisp translate to Go?</p> <pre><code>defun compose (f g) #`(lambda (x) funcall f (funcall g x)))) </code></pre> <hr/>**评论：**<br/><br/>SteveMcQwark: <pre><p>Go is not a functional language. It does have closures, but it doesn&#39;t in any way encourage function combinators and such. In particular, its lack of generics makes it next to impossible to write such a function. You could <a href="http://play.golang.org/p/JNuk9ws7wF">use reflection</a> if you really wanted to, but you probably shouldn&#39;t.</p></pre>swisskid22: <pre><p>Go does have some functional language features, like lambdas and higher order functions. This said, it lacks one major feature which many functional techniques rely on-- generic types. The absence of this feature is a heavily debated topic amongst go programmers, and the language designers have made it pretty clear that they don&#39;t plan on adding it anytime soon. Because of this, a general <code>compose</code> is all but impossible ( without some horrible <code>interface{}</code> hack that requires explicit casts ). That said, go has lambdas and higher order functions, so we can do a version like this with types specified:</p> <pre><code>func compose(f func(int) int, g func(int) int) func(int) int { return func(arg int) int { return f(g(arg)) } } </code></pre> <p>This probably isn&#39;t what your looking for, but if you don&#39;t need a type-general version this can be used. </p> <p>Go is a great, opinionated language, but it won&#39;t be as expressive as something like lisp, haskell or scala and this is intentional. </p></pre>SteveMcQwark: <pre><p>I strongly suspect that the &#34;right&#34; way to do it is to just directly write the closure inline. Sort of like how the Go authors encourage you to just write the darn loop rather than trying to write map, filter, etc... operations.</p></pre>tv64738: <pre><p>In general, don&#39;t program language $X as if it was language $Y. Don&#39;t program Haskell like it&#39;s C. Don&#39;t program Python like it&#39;s Java. Don&#39;t program Go like it&#39;s Lisp.</p> <p>The point of each language is the design trade-offs it makes. If you don&#39;t internalize those trade-offs, and adjust your style to them, you will be missing the sweet spot of whatever $X happens to be this time around.</p> <p>For Go, the trade-offs are very, very consciously chosen, and a critical part of the reason for the whole language to exist.</p></pre>dfuentes: <pre><p>You&#39;d probably need to declare the argument and return types for the functions you are composing and do something like <a href="http://play.golang.org/p/rkOd1DnXid" rel="nofollow">http://play.golang.org/p/rkOd1DnXid</a></p></pre>