Problem with list

I am using this for the first time, and just can't make it work. I declare the list as a global variable, at the top of the script, in this form:-

list vowels=["a","e","i","o","u"];

But when I refer to the list anywhere in the script, as in stringletter=vowels(3);, I get the error 'Name not defined within scope'.

Is list treated as a variable, or are there special rules that apply?

Should look a little something like this...

list vowels = ["a","e","i","o","u"];

default
{
    state_entry()
    {
        llSay(0, (string)llList2String(vowels, 3)); 
    }
}

Reitsuki,

Didn't realise you had to do that. Anyway, it works perfectly; thanks very much.

Ya, they are list not arrays :\ Go vote to have arrays!!!

You don't need to type cast a string into a string.

llSay ( 0 , llList2String( vowels, 3 ) );
would work fine.

Thanks, Jade.

As long as we're on the topic, isn't there an easier way to modify a single element in a list (i.e. lstThings[5] like in an array) without creating a whole new single element dummy list and merging it?

There *has* to be a better way but I can't find it anywhere in the Wiki :-/

You could do a list replace, and use index, index as the start and end locations to replace. Other than that, I'm not sure there is any easier way.

Arrays and user-definable structures. Mmmm.....

Yeah, you can just use llListReplaceList, and turn the replacement element as a list inside the call, it's not too bad.

http://secondlife.com/badgeo/wakka.php?wakka=llListReplaceList

myList = llListReplaceList(myList, [replacement], index, index);

Oops sorry, I meant replace, not merge.

llListReplaceList requires a new dummy list to be created, which is rather a pain. But if that's the only way, then that's the way I'll need to do it

Thanks for posting this example, Ordinal. This is the kind of thing that is so odd, I had trouble believing it would be the solution.

As nice as it would be to have single index replacement, it simply wouldn't work in the context of SL. SL's language works on largely pass by value stack based non-mutable data types. Basically, a list is a large block of data that cannot be altered, only replaced. This is done mostly in an attempt to keep the system secure. It also makes things extremely memory intensive (since to pass a list to a function you have to push the entire list to the stack rather than just a reference to it).

Babbage Linden is working on intergrating mono CIL into the sims. When that happens, I'm sure we will see much faster execution times and better memory efficency. CIL lets you pass by reference, it has better memory management, and it has dynamic recompilation to machine code so execution speed for scripts that are inworld for an extended period of time and contain reused code will increase.

Wow, that was a tangent. But that's why you can't do list[x] = 5;

All I can say is you'll just have to wait.

Kalleb - Thanks for the info. Still, I'm not sure why the API can't include llSetStringInList(list src, string str, integer index), etc. even if they have to implement it internally with llReplaceList().

I'm going to venture a guess that it would be considered "not nessessary", since it can be done with a few simple calls. I mean, in theory, they could emulate mutable lists by allowing parsing like myList[0] = "argh!"; to myList = llListReplaceList( myList, ["argh!"], 0, 0 );

I guess a more reasonable demand would be to request compile time macros and inlined functions.

I doubt we shall see any major changes to things like this until mono deploys. The LSL compiler has numerous problems that they have been neglecting to fix for some time, unless it provides new functionality, they don't generally think very long on it.

Kalleb - I agree it's not necessary. My argument for including it in the API would simply be that it's clearer and simpler. When I wanted to know how to set a string at a position in a list, I naturally looked for a call symmetrical to llList2String().

But I think the overall problem, in this respect, is that SL was designed as a game, not as a software development platform. Maybe SL 2.0 will be designed differently. CIL is encouraging.

If they used reference counts and deferring copies until a list needed to be changed, it would be possible to avoid many of the copies they currently do and even have llListReplaceList and similar calls operate in-place with only a little effort.