We should make our slicing and assignment ops more general to capture more of the functionality of numpy slicing, and add __getitem__ sugar for all of it. Specifically,

1. We should have a 2.5 dimensional set of ops, with dimensions (1) get vs. set, (2) slice type, and for the assignment ops (3) the update op. Currently we have slice, assign_update, assign_add, assign_sub, gather, scatter_update, scatter_add, scatter_sub. We should also have assign_slice_update, assign_slice_add, assign_slice_sub.
2. Both slicing and slice assignment should support strides, with no performance cost if strides aren't used.
3. Ideally, the slice ops should support negative indexing a la Python. Since the slice parameters are already CPU, this is implementable with near zero cost. The unfortunate bit is that since we picked the wrong format for specifying ranges (start + length instead of start : end), negative indexing might be awkward. Thus, it might be best left to a separate bug.
4. Support numpy-like boolean indexing.
5. Generalize gather and scatter_* to take an array of input index tensors, efficiently broadcast them, and do multidimensional indexing similar to numpy.
6. Make __getitem__ provide sugar for all of the above. Ideally we'd have something idiomatically similar at least to __setitem__, but this is problematic since the returned assignment op is important to have, __setitem__ does not return a value, and the nice range sugar is available only inside indexing / assignment calls.

@ebrevdo: I'm assigning this to you for now since you might get to it first, but feel free to grab only the piece of it that you need for now.