Array slicing

[Richard Russell]

Does Matrix Brandy have any way (even a hidden method) of implementing array slicing, i.e. the ability to create a 'child' array which corresponds to part of a 'parent' array? Conceptually I'm envisaging something like this:

      DIM parent(9)
      parent() = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10

      PROC_arrayslice(parent(), child(), 3, 5)
      child() = 11, 12, 13

      FOR I% = 0 TO 9 : PRINT parent(I%); : NEXT

which would print 1 2 3 11 12 13 7 8 9 10

I have no such capability in my BASICs, and that has been identified as a weakness when compared with Python. So I'm wondering if the effort and risk involved in adding such a functionality could be justified. If Brandy already has it, or it can easily be added, it would be an argument in favour.

Soruk

It is not currently supported (and apart from C, where playing with pointers would be the way to do this) I've not come across this. Still, given enough time I'll see what might be involved in doing this.
For syntax (and this is just a back-of-an-envelope initial thought) the syntax could be something like:
DIM child% ON parent%(), start%, end%
Of course, child% and parent% must be of the same type.

[Richard Russell]

Soruk wrote: »

For syntax (and this is just a back-of-an-envelope initial thought) the syntax could be something like:
DIM child% ON parent%(), start%, end%
Of course, child% and parent% must be of the same type.

If I do it in my BASICs, there will be no "syntax" as such because it won't be a language feature! What I am considering is purely enabling it in the interpreter, not implementing it. The actual implementation would be in BASIC code, hence what I listed above:

PROC_arrayslice(parent(), child(), 3, 5)

where PROC_arrayslice() would be in a library. Currently, writing that library code is impossible, but by making small changes to the interpreter's code (changes which hopefully wouldn't increase the size by even a single byte) it could in principle be made possible.

At this stage, I would not consider changing or adding to the language specification. If you want to do that can I suggest you concentrate on features that my BASICs already have, such as structures!

[Richard Russell]

I should add that I would expect only one-dimensional arrays to be 'sliceable', because of the way the data is laid-out in memory. It looks like you have made the same assumption from your suggested 'syntax'.

[Richard Russell]

Soruk wrote: »

Of course, child% and parent% must be of the same type.

That would be a reasonable limitation for a 'built in' syntax, but one advantage of the approach I am considering (low-level 'enabling' code in the interpreter, high-level implementation code in a library) is that such a restriction isn't inherent.

For example one would be able to use the low-level extension to create a 'byte' array array&(15) which represents the same memory as an integer array array%(3), with the four elements array&(0) to array&(3) mapping to the single element array%(0) for example. I can see that being quite useful.

The fact that my approach is limited to one-dimensional arrays does restrict such applications, but it's the only way that I can add the 'enabling' code without increasing the size of the interpreter by even a single byte, which is important for code-alignment reasons.

[Richard Russell]

Soruk wrote: »

DIM child% ON parent%(), start%, end%

I'm not planning on making it a native capability, but if I were I might suggest something like:

DIM child%() = parent%(start% TO end%)

or

DIM child%() = parent%(start% BY count%)

This has a nice resonance with my structure-array declaration syntax.