On Fri, Jan 30, 2009 at 8:00 AM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> Jarrett Billingsley wrote:

>> Sounds good.  Question - since length will work for multiple indices, will it ever be possible to have .. multiple slices?
>>
>> a[x1 .. x2, y1 .. y2] = b;
>
> That's rather exotic. After that the road is opened for free-form combinations of a .. b and a. But I can definitely see some good uses for it.

Multi-dim slicing is bread and butter for array math packages like Matlab or NumPy.

--bb

On Thu, Jan 29, 2009 at 6:00 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>
>> a[x1 .. x2, y1 .. y2] = b;
>
> That's rather exotic. After that the road is opened for free-form combinations of a .. b and a. But I can definitely see some good uses for it.

Hm.. if you _wanted_ to interleave slices and single indices, how would you do it?  How about we take a page from Python's book: it doesn't (used to but no longer) distinguish between slicing and indexing.  It uses the same "operator overload" for both, but slicing passes a 2-tuple as the "index", kind of like:

blah opIndex(int x) // used for a[0]
blarg opIndex(Slice!(int, int) x) // used for a[0 .. 1]

Assuming we have a "struct Slice(Lo, Hi) { Lo lo; Hi hi; }" type.

Then, you could just have opIndex[Assign] take multiple parameters - like it does now.  And of course, it could just take a tuple and figure out what to do based on whether each thing is an int or if it's a slice.  Complex, but completely doable, and it still leaves simple cases simple.

Jarrett Billingsley wrote:
> On Thu, Jan 29, 2009 at 6:00 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>>> a[x1 .. x2, y1 .. y2] = b;
>> That's rather exotic. After that the road is opened for free-form
>> combinations of a .. b and a. But I can definitely see some good uses for
>> it.
> 
> Hm.. if you _wanted_ to interleave slices and single indices, how
> would you do it?  How about we take a page from Python's book: it
> doesn't (used to but no longer) distinguish between slicing and
> indexing.  It uses the same "operator overload" for both, but slicing
> passes a 2-tuple as the "index", kind of like:
> 
> blah opIndex(int x) // used for a[0]
> blarg opIndex(Slice!(int, int) x) // used for a[0 .. 1]
> 
> Assuming we have a "struct Slice(Lo, Hi) { Lo lo; Hi hi; }" type.
> 
> Then, you could just have opIndex[Assign] take multiple parameters -
> like it does now.  And of course, it could just take a tuple and
> figure out what to do based on whether each thing is an int or if it's
> a slice.  Complex, but completely doable, and it still leaves simple
> cases simple.

That's exactly what I did in Blade. opSlice() is a dead end.
The algebra for combining consecutive slices is quite interesting, but it's not really that complicated. You can always transform any expression like:
x[3..5, 6, 2..$][4, $][5..$][3..7][6];
into a single mixed opIndex() call.
You can do mixed index and slices either by making every slice a tuple, or by having a bool array stating whether each entry is an index, or just the second part of a slice. (This way every parameter in opIndex is the same type:  there's less template bloat).