<p>Is there any way to curry a function in go?</p>
<hr/>**评论：**<br/><br/>dvirsky: <pre><p>You mean something like this?</p>
<pre><code>func sum(x, y int) int {
return x + y
}
func partialSum(x int) func(int) int {
return func(y int) int {
return sum(x, y)
}
}
func main() {
partial := partialSum(3)
fmt.Println(partial(4)) //prints 7
}
</code></pre></pre>PM_ME_YOUR_VIMRC: <pre><p>Yes, thank you</p></pre>liflo: <pre><p>When would this type of solution be better than something simpler? Just trying to wrap my head around it...</p></pre>hobbified: <pre><p>Still slightly contrived, but a common case is something like you have one package that provides</p>
<pre><code>func WriteToHandle(w *io.Writer, g Gizmo) error
</code></pre>
<p>and another package that wants a callback in the form of a</p>
<pre><code>func (Gizmo) error
</code></pre>
<p>so you might find it useful to define your own</p>
<pre><code>func MakeGizmoWriter (w *io.Writer) func (Gizmo) error {
return func (g Gizmo) error {
return WriteToHandle(w, g)
}
}
</code></pre>
<p>and then you can pass the value of <code>MakeGizmoWriter(os.Stdout)</code> in as the callback.</p>
<p>The contrived aspect of that is why <code>WriteToHandle</code> isn't actually a method of <code>Gizmo</code> or some interface that it does, but I'm not feeling very creative today. Examples like that <em>do</em> come up in reality :)</p></pre>theonlycosmonaut: <pre><p>I often use this pattern in JavaScript when, for example, I want to construct different functions with the same essential structure, but a couple of different values. Most recently, some button events:</p>
<pre><code>button1.onclick = makeEventHandler(1);
button2.onclick = makeEventHandler(2);
function makeEventHandler(val) {
return function(event) {
console.log('button', val, 'clicked');
};
}
</code></pre>
<p>Contrived example for simplification, obviously. In my actual case, the inner function was about 20 lines long.</p>
<p>The example <a href="/u/dvirsky" rel="nofollow">/u/dvirsky</a> gave was also contrived - but essentially, this type of solution is useful because it often <em>is</em> simpler. <a href="/u/hobbified" rel="nofollow">/u/hobbified</a>'s example could be implemented by creating a struct with a Writer member and a method that accepted a Gizmo, but sometimes just wrapping a function in a function is the easiest solution.</p></pre>dvirsky: <pre><p>Personally I'm using this pattern for http handlers. You initialize an http handler with some state within a closure, and then return it for normal processing. </p></pre>ericanderton: <pre><p>There are situations where passing a <code>func</code> instead of a concrete type is more convenient and creates a more fluent API. Especially since Go supports anonymous closures.</p></pre>hobbified: <pre><p>sure, although unless you use reflection to do it it's going to be a bit verbose. The toy example: <a href="http://play.golang.org/p/qpkRam5VX4" rel="nofollow">http://play.golang.org/p/qpkRam5VX4</a></p></pre>sleep_well: <pre><p>Go is not a functional language and does not intend to be one. Unless absolutely necessary, avoid forcing functional idioms in go code .</p></pre>binaryblade: <pre><p>Functions are first class objects in go and are designed to be used as such.</p></pre>quiI: <pre><p>There is a massive difference between a functional language and "functions are first class". Although I guess this depends on who you ask. </p></pre>szabba: <pre><p>That doesn't mean all idioms involving first-class functions in other languages are going to be idiomatic Go.</p></pre>PM_ME_YOUR_VIMRC: <pre><p>Does go have closures?</p></pre>sergei1980: <pre><p>Yes, Go has closures.</p></pre>binaryblade: <pre><p>yes</p></pre>613style: <pre><p>Not sure why you're getting downvoted since you're completely right. While functional ideas are often possible in Go, it's not idiomatic and the code is long and ugly.</p></pre>binaryblade: <pre><p>because the question was not about whether or not this Haskell program could be ported wholesale, it was about whether or not currying could be accomplished. Currying is present is a great number of languages such as C++ with std::bind and while is function focused is not something which should be outright dismissed based on some puritanical idea that go does not contain any functional concepts ever.</p></pre>
