4 ms·
This only handles functions of type a -> a -> a (https://github.com/robpike/filter/blob/master/reduce.go https://github.com/robpike/filter/blob/master/reduce.go
by hyperpape 12y ago
This only handles functions of type a -> a -> a (https://github.com/robpike/filter/blob/master/reduce.go https://github.com/robpike/filter/blob/master/reduce.go), whereas a generic reduce takes functions of type a -> a -> b. So this is certainly not proof that you can write generics in go. See also pmahoney's comment in this thread: https://news.ycombinator.com/item?id=9315721 https://news.ycombinator.com/item?id=9315721.
- epidemian 12y agoMinor nitpick: a generic reduce should take functions of type a -> b -> a, where a is the type of the reduced values, and b is the type of the elements in the sequence to be reduced.
- hyperpape 12y agoAh, of course.
- amscanne 12y agoYou could very easily relax that constraint by changing a couple of lines. Rob Pike has simply chosen the classic MapReduce form. I'm not sure why you would need "proof" that generics are possible in Go. You have reflection and type assertions, and their capabilities are well documented. Does it give you generics? All depends on your definition of generics.
- masklinn 12y agoAnd even with that, it still returns an interface{} which you need to cast.
- falcolas 12y ago> This only handles functions of type a -> a -> a So, since his toy code was explicitly written to accept the same type for both parameters of the function, you are unable to see how it could be modified to accept a different type signature for the reduce function? It looks to me like a fairly trivial change to get the type of argument `zero`, and use that as one of the parameters to the reduce function. As for pmahoney's comment, looks like there's a bug. Perhaps he should file a bug report, or pull request.