C Style Array Implementation

This one is for you scripters who are just as frustrated by lists.
I find lists abhorrently inneffiecient when it comes to raw data crunching when it comes to some more advanced scripts. They are also far harder to modify (3 lines of code to change a value as opposed to one for a C Style Array). Any of you scripters or even not scripters who want to see scripts around them taken to new heights please post your support here.

For those of you familiar with LSL but not C style arrays here is an example:

Integer Num_list[50]; //Declares 50 integers

(the list way would be typing
list Num_list [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0];

String Bob[10];
Bob[3]="Randomword"; //Changes element 4 of bob to randomword

I second that --- and so should Linden Labs, because it would increase the efficiency of the language and hence decrease server loading.

In case it's a non-tech that's reading this, the efficiency would be increased (dramatically) because array indexing is performed by a single minimum-cost instruction opcode in all current-day CPUs, in contrast to list traversal which typically requires multiple operations. Ie. array indexing scales O(1) with a near-zero fixed cost, vs O(n) for linear lists.

Dougal Jacobs' specific proposal for a simple fixed-length, single-dimension, single-type array with no frills is fine too. While we all like the flexibility of Perl-type associative arrays or any kind of hashed-index expandable array in general, that's not what LSL needs (and I guess nor what Linden does either) --- efficiency is what matters, because it translates directly into running cost. And fixed-length, single-type arrays are very simple to implement, including the trivial but necessary index bounds-check.

Syntax:

<type_keyword> <array_name> '[' <size_expression> ']' ';' // Looks good to me, and it's in keeping with the prevalent C style.

Semantics:

- Index range should be [0 .. (N-1)] in keeping with all other ranges in LSL.

- Accesses outside of [0..(N-1)] should raise a runtime error if the value of the errant index can be reported.

- If the value of a bad index cannot be reported easily, returning the normal uninitialized value for the member type would be an alternative.

- The types of the indexing expression and of the RHS of assignments can be determined at compile time, so no new issues here.

- The <size_expression> could be any integer expression for declarations inside a code block, but only a literal when declaring a global array.

- Array initializers: either don't bother (if it raises the bar for implementation), or else just reuse the existing list initialization code, with an additional type-check on each element and on the field count.

Thanks for your support. I hope the Lindens take a look at this thread... this is a terribly simple change that i would almost prefer came before Havok 2. Right now we cannot keep track of information about many individual objects or avatars or such because of the list implementation. I can imagine quite a few things i would be able to make given these changes.

Khamon Fate's post, Eggy's, and mine were all lost from this thread in today's SL forums crash.

I won't repost mine from my browser cache unless Khamon reposts his, since mine was in reply to his point.

Ah, one of the reoccuring topics: Pointers.

If we don't have pointers, then C-style arrays are just a reformatting of what we already have:
llList2String, llList2Int, etc.

If we do have pointers, either SL will be insecure, or there will be so much security checking that it will make them not much of an efficiency upgrade.

Sorry Hiro, but that's entirely incorrect. The technology doesn't work that way.

Pointers would not need to be exposed in the user-accessible language for real lightning-fast array subscripting to work. The integer index generated by the user's indexing expression is first trivially bounds-checked to fall within the size of the array, and only then is it added to the internally-held base address, which then yields a 100% safe object location within the contiguous array.

Also, array indexing has no simiilarity at all with list indexing. Array indexing is an O(1) operation, ie. constant time (and very tiny constant time at that), whereas all linear implementations of lists have O(n) traversal time and hence scale badly in comparison (aka. use up server CPU time unnecessarily during traversal). These are two completely different things.