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.
