When does (list)x != [x] ? (and why!)

I'm at a loss.

I have some code that wouldn't work. Grasping at straws, I changed:

ix = llListFindList(mylist, (list)((string)id));

which wouldn't find the item that IS there, to

ix = llListFindList(mylist, [ (string)id ]);

and now it WORKS!

What could possibly be the difference between (list)(expr) and [(expr)] ??
The second form is clearly necessary when there's more than one element. But when there's only one, how could they be different?

Thanks!

I'd love to know what was causing that because those are logically the same operation. unless there's some weirdness with the type casting, and the actual found data not being of that type? (one version slipping through and one not?)

for instance, perhaps the type you're looking for is a key, even though the search term is string, but one method (the latter?) is ignoring the typecast?

that's just a wild guess.

That was my first guess too, and it turns out to be right. I don't know why (list) seems to ignore the string typecast, but it does. I never use (list), personally. I believe (list) uses less memory, but it also makes code less readable..

Edit: Here's an awesome example of (list) being broken.. apparently it converts strings that are valid keys INTO keys automatically.

string me = (string)llGetOwner();
list temp = (list)me;
llSay(0, (string)llListFindList(temp, [me]));

Result: "Object: -1"

Edit 2: I lied. See the following.

string me = "322a2c64-09d2-4d5b-a361-f644eabb5d9c";
list temp = (list)me;
llSay(0, (string)llListFindList(temp, [me]));

Result: "Object: 0"

Now I'm super confused. I guess this has more to do with how the data is stored and manipulated on the stack, and precisely when the typecasts occur.

And again.. it gets better:

string me = "";

default
{
state_entry()
{
me = llGetOwner();
}

touch_start(integer number)
{
list temp = (list)me;
llSay(0, (string)llListFindList(temp, [me]));
}
}

STILL can't find the string. So I guess key types returned from functions and stored in string variables actually retain their key type in a list when typecasted with (list). Whew. I'd call it a bug, though.

I don't know the answer but am curious if "ix = llListFindList(mylist, (list)id);" would work...

Yes, i've encountered that in the past, chalked it up to more LSL wierdness. :\

Interesting!

I also immediately thought it was related to data type -- i.e., I'd stored a key but was looking for a string. Well, I found I was definitely storing a string (that is, Miffy Fluffy was ... modifying his code). So I abandoned that tack, without considering the possibility that it's the double cast that's not working!

I use "list)" all the time just to save memory, and I find it easier to read. However, in the future I won't use it with a cast. Tyken, while your precise hypothesis might not have been correct, I pretty strongly suspect that multiple typecasting is the cause of the problem.

BTW, I haven't ever tried to figure out whether casting takes less bytecode or uses less runtime memory, as opposed to the list constructor. If anyone happens to know, I'm all ears!

Thanks
Jeff

PS: Void, am I mistaken or did you post somewhere that you were relatively new to programming when you started LSL? If it's true, it's remarkable because your posts show great insight. I suspect it's just that my memory has mislead me again!

I really, REALLY hope they take the same amount of runtime memory, but then again, we've clearly just seen that they're not the same operation.. I'd wager that using the normal brackets takes up both more bytecode AND runtime, though, since it likely does a lot more (as it builds multi-element lists).

I think casting to a list is ambiguous. for example (pseudocode alert...

string foo="[a,b,c];

list bar = (list)foo;

As a language *designer*, I could either chose to interpret the string foo as a list and create the list [a,b,c], OR I could create a one element list with the string foo as the only element.

Does that make any sense?

I think people might argue about which should be the default behavior. I think the correct behavior might be unspecified by the IEEE 2011 LSL standard specification.

I think you're crazy. I also suspect you're new to language design & implementation. I admit I've been away from that for a couple decades.

A string is a string. Casting a string to a list should cast it to a list with a single element, the string -- just as it would for any other non-list data type, like integer.

Converting a string to a list is the kind of thing a function should do, such as llParseString2List or llCSV2List.

I've never trusted casting to lists for some reason. I think it had to do with comments I've seen to this effect, and my own scary little "gotcha" experiences. Better to be darn explicit. I NEVER typecast to a list, and I ALWAYS add lists to lists rather than atomic types: myList + [ value ], not myList + value

No, not crazy, and more decades of language design than you, I'll warrant.

nope not new to programming, although I don't have as many years as some, it all started with an apple2e, go, and basic, back in the day. I do suspect I have a higher percentage of OOP and EDL experience, so old FDL habits were easier to break.

so by tykens testing, it's not list that's failing it's string typcasts on keys that are being compared in lists? if so, does anyone feel like definitely testing the types of the stored and compared values, using different methods?

now I haven't dived into the bytecode like strife has, but I do know that that the list typcast vs brackets for single elements runs a little leaner. I presume that's because the brackets actually reserve variable space in the compile, while the typcast does this on the fly.

so using that as the starting point the inductive logic is that there is something wrong with typecasts, either being ignored (like my first guess) or misbehaving as in tykens test.

now if the types come back kosher for all variations, there's one other possibility... list find is doing something it shouldn't, and either ignoring a tpyecast, or forcing one (depending on the type comparisons, I'm not sure which)

nope not new to programming, although I don't have as many years as some, it all started with an apple2e, go, and basic, back in the day. I do suspect I have a higher percentage of OOP and EDL experience, so old FDL habits were easier to break.

so by tykens testing, it's not list that's failing it's string typcasts on keys that are being compared in lists? if so, does anyone feel like definitely testing the types of the stored and compared values, using different methods?

now I haven't dived into the bytecode like strife has, but I do know that that the list typcast vs brackets for single elements runs a little leaner. I presume that's because the brackets actually reserve variable space in the compile, while the typcast does this on the fly.

so using that as the starting point the inductive logic is that there is something wrong with typecasts, either being ignored (like my first guess) or misbehaving as in tykens test.

now if the types come back kosher for all variations, there's one other possibility... list find is doing something it shouldn't, and either ignoring a tpyecast, or forcing one (depending on the type comparisons, I'm not sure which)

Hah, months later, I read this to find that I *wasn't* losing my mind!

(I ran into this myself a while back when using llListFindList)

I went digging through the code, found the bugs that lead to this and posted a couple of patches.

http://jira.secondlife.com/browse/SVC-1710

I just hope they work.

OK, I aplogize for the snide remark, but I would consider it a very bad language design choice to embed such logic into a cast. Clearly, it's not what LSL does, since it has different functions for similar purposes, thank goodness.

Way to go Strife!

I also found a related bug (and have updated my patch). This results in both the first and the last to remaining keys:

((string)mKey) + mList + ((string)mKey)

I wondered where and when the idea of treating keys and strings equvalently would bite them... not nearly as bad as I expected.

It's really only a small oversight. They had identified and fixed the problem for key+list and list+key; they just didn't see the inverse of it ever happening or figure out why it was happening at all.