Any particular reason why ss and rs are not exported

[standy66]

Hi!
I would like to use this library for tensor manipulations in Golang. Is there any reason as to why range slices and single element slices are not exported in slice.go? It would be very convenient if they were exported, e.g. like this:

func RangeSlice(start, end int, opts ...int) Slice {
...
}
type SS int

[chewxy]

The reasoning behind this is mostly a game theory thing.

The tensor.Slice interface is the primary method in which tensors are sliced. That means anything that implements the tensor.Slice interface can be passed into a .Slice(...) method as required by the tensor.Tensor interface.

The main reasoning behind the Slice interface is so that a Gorgonia Op (*sliceOp) can implement tensor.Slice. This is to facilitate a symbolic representation of operations in package tensor.

Not exposing the internal concrete structures was basically a way to enforce that a proper think through is required when using slices. For example, in a logic programming language I created using package tensor, I had to think hard about using slices. In the video I linked, I mentioned that the CKY parse produces a matrix of something called a CatSpanner. A CatSpanner also implements tensor.Slice. It's a pretty sophisticated use. Had I exposed the internal concrete structure I would have used it but then I would have to create a new type that does something different for CatSpanner.

Furthermore, exposing the internal concrete type that implements Slice would simply add to the confusion - e.g. why are there so many types of notion of slice!?

Now, I will admit that this causes usability issues - if you have to reimplement the interface every time it would be very inconvenient!

I'm open to suggestions - the best suggestion so far was that we should have another package - a tensorutils package, which comes with all the helpers.

Another suggestion is something like gorgonia.S which simply exports makeRS.

Happy to hear your thoughts. @standy66