Dear
Jürgen,
For starters, this discussion, in my mind, is just academic at this point. Not knowing the details of GNU APL, I will speak somewhat abstractly.
1. The intent is to save space and not time. The space savings, depending on the application, can be extremely high.
2. The time cost could easily be made next to zero IMO. Imagine your existing code with just one IF statement added to each function. IF special iota array do new code, otherwise do normal/regular/old code. Time hit on normal/regular/old code is next to zero in this case.
Here is an important idea, you don't create special iota arrays in every case. You only do so when the array would be over a certain size threshold - perhaps programmer definable. This way, again, we are left with no time hit when using normal arrays, and small iota arrays will be expanded as they are now. So, the cost only comes for large arrays - you know - the ones that have a huge space cost.
Let's look at time hits on special iota arrays. There are only three things you can do with an array:
a. Get elements (i.e. x[400], y[633;], z, etc.). In this case you calculate the result rather than just get the data. You can also associate usage heuristics with each array so you can calculate when it just makes sense to expand the array to a normal array.
b. Put elements (i.e. x[567]←55). In this case, if the array element is actually being changed (as opposed to putting the same value), you always have to expand the array. Timing again gets reduced to the same as normal arrays.
c. Copy array (i.e. x←y+2 : x becomes a modified copy of y). In this case y is not modified and need not be changed. x uses your normal algorithm for creating arrays (normal or special iota arrays). If it is a special iota array, the copy will be significantly faster.
So it seems the space savings can be extremely significant, and there are times when their is a significant time savings too. Normal time costs (when dealing with normal arrays) is near zero. Time costs, in worse case scenarios for special iota arrays can be largely eliminated with a small amount of usage statistics and forced expansion.
Now, with all the other stuff going on, I consider this an academic discussion and not a feature request.
Thanks.
Blake