making generic algorithms in go

I can't figure out a clean way to implement an algorithm that will work on any type.

The following code will produce errors trying to convert a string or a typed slice into interfaces, and you can't compare interface{} objects: invalid operation: result[0] > result[n - 1] (operator > not defined on interface)

func main() {
    c := Algo("abc")
    //...
    c := Algo([3]int{1,2,3})
    //...
}

func Algo(list []interface{}) chan []interface{} {
    n := len(list)
    out := make(chan []interface{})
    go func () {
        for i := 0; i < n; i++ {
            result := make([]interface{}, n)
            copy(result, list)
            // an actually useful algorithm goes here:
            if (result[0] > result[n-1]) {
                result[0], result[n-1] = result[n-1], result[0]
            }
            out <- result
        }
        close(out)
    }()
    return out
}

Although it's a pain (I think it should be automatic), I can manually box and unbox typed slices into interface{}s, the real problem above is the comparison. And it just keeps getting more and more kludgy.

a := [3]int{1,2,3}
b := make([]interface{}, len(a))
for i, _ := range a {
    b[i] = a[i]
}

I've even thought of using vector.Vector, but so many people say never to use them.

So should I just implement the same algorithm for int slices and strings? What about slices of myObject? I can make an interface with a custom comparison func, but then how do I make it work with standard types?

You can do this in Go using interfaces. A function that takes an interface type is generic in the sense that it doesn't care about the data representation of the underlying concrete type. It does everything through method calls.

To make a generic version of your algorithm then, you have to identify all of the capabilities that the algorithm requires of the data objects and you have to define methods that abstract these capabilities. The abstract method signatures become method sets of interfaces.

To make a type compatible with this kind of generic algorithm, you define methods on the type to satisfy the interface of the algorithm parameter.

I'll take your example code and show one way to do this. Most of the required capabilities happen to be covered by sort.Interface so I chose to embed it. Only one other capability is needed, one to make a copy of the data.

type algoContainer interface {
sort.Interface
Copy() algoContainer
}

Below is a complete working program made from your example code.

package main
import (
"fmt"
"sort"
)
func main() {
s1 := sortableString("abc")
c1 := Algo(s1)
fmt.Println(s1, <-c1)
s2 := sortable3Ints([3]int{1,2,3})
c2 := Algo(&s2)
fmt.Println(s2, <-c2)
}
type algoContainer interface {
sort.Interface
Copy() algoContainer
}
type sortableString []byte
func (s sortableString) Len() int { return len(s) }
func (s sortableString) Swap(i, j int) { s[i], s[j] = s[j], s[i] }
func (s sortableString) Less(i, j int) bool { return s[i] < s[j] }
func (s sortableString) Copy() algoContainer {
return append(sortableString{}, s...)
}
func (s sortableString) String() string { return string(s) }
type sortable3Ints [3]int
func (sortable3Ints) Len() int { return 3 }
func (s *sortable3Ints) Swap(i, j int) {
(*s)[i], (*s)[j] = (*s)[j], (*s)[i]
}
func (s sortable3Ints) Less(i, j int) bool { return s[i] < s[j] }
func (s sortable3Ints) Copy() algoContainer { c := s; return &c }
func Algo(list algoContainer) chan algoContainer {
n := list.Len()
out := make(chan algoContainer)
go func () {
for i := 0; i < n; i++ {
result := list.Copy()
// actually useful:
if result.Less(n-1, 0) {
result.Swap(n-1, 0)
}
out <- result
}
close(out)
}()
return out
}

Since the Go Programming Language doesn't currently support generic types, this is going to be hard to do.

> Why does Go not have generic
> types?
>
> Generics may well be added at some
> point. We don't feel an urgency for
> them, although we understand some
> programmers do.
>
> Generics are convenient but they come
> at a cost in complexity in the type
> system and run-time. We haven't yet
> found a design that gives value
> proportionate to the complexity,
> although we continue to think about
> it. Meanwhile, Go's built-in maps and
> slices, plus the ability to use the
> empty interface to construct
> containers (with explicit unboxing)
> mean in many cases it is possible to
> write code that does what generics
> would enable, if less smoothly.
>
> This remains an open issue.

Look at the Go sort package to see how it handles comparisons and other operations specific to a type by defining the sort.Interface type with Len, Less, and Swap methods.

Go does not have generic types, but you can take a look at how <a href="http://golang.org/pkg/sort/">sort</a> works to find a workaround. What they do is create an interface like this:

type Interface interface {
// Len is the number of elements in the collection.
Len() int
// Less returns whether the element with index i should sort
// before the element with index j.
Less(i, j int) bool
// Swap swaps the elements with indexes i and j.
Swap(i, j int)
}

And now for any custom type you can make a corresponding custom collection type that can be sorted. The sort algorithm only has to deal with integers and booleans, and so doesn't see or care what the underlying data types are.