Proposal: Multidimensional opSlice solution

[Don]

Norbert Nemec wrote:
> Don wrote:
>> Norbert Nemec wrote:
>>> The compiler would need to be aware of the data type Slice. It would 
>>> therefore have to be something like a "builtin" type. If I am not 
>>> mistaken, the language definition so far never makes use of "builtin" 
>>> struct types.
>>
>> You are mistaken <g>.
>> object, TypeInfo, AssociativeArray, ...
>> Complex will be added to that list, too.
> 
> Indeed? If that is so, a builtin Slice type as syntactic sugar would be 
> just as good as my proposal. 

 > Just note that the slice operator "a..b" should also allow strided 
slicing "a..b:c"
That's a lot less clear. I don't want to touch that issue right now.

Anyway, you've convinced me that the int[2] option doesn't work for 
slice information.


>> Agreed. Multidimensional slicing is a costly operation, though, so I 
>> think the absence of syntax sugar is tolerable.
> 
> Costly? Not at all! Just a bit of integer arithmetic that would need to 
> be done anyway to access the data. Most numerical code consist of many 
> nested loops containing very few operations. Strided multidimensional 
> slicing operations in combination with array expressions allow to 
> express this equivalently in very few lines that can be optimized very 
> effectively.

You're correct about what they do, but I think the conclusion is wrong. 
Multidimensional slices normally result in appallingly inefficient use 
of caches. Unless you do something extremely clever.
So I think the onus is now on library developers to show that it's 
possible to create a compelling library which makes efficient and 
intuitive use of multidimensional slices. I think by the time that task 
is accomplished (which I imagine may take a couple of years), the 
language will be ready for a minor update. It's only a minor syntax tweak.