Category talk:LSL Operators

Operator Associativity & Precedence

some of the operator associations such as && || are actually left to right, (0 && 0 || 1) == TRUE, (1 || 0 && 0) == FAlSE, and are easy to list as such, but I'm assuming that single operator precedence levels (like bitwise &) are preferred to be listed in the compiled code order (right to left), where testing shows that order doesn't matter to execution? originally I had listed those as left to right as a matter of convenience, but I can see the value of reinforcing the knowledge that LSL is compiled in general right to left asociation, with exceptions to certain operations. I'm still testing some precedence associations, so I'll update as that occurs.
-- Void ^{(talk|contribs)} 03:29, 11 January 2010 (UTC)

update:
all infix math operators are LtR (not suprising as they'd have issues otherwise), as are bitshift, and comparison operators, as demonstrated by the following equations that all evaluate to true in LSL
((4 / 2 / 2) != (4 / (2 / 2)))
((1 + 1 - 1 + 1) != (1 + (1 -( 1 + 1)))
(2 >> 1 >> 1) != (2 >> (1 >> 1))
(1 > 1 > 1) != (1 > (1 > 1))
(2 == 2 == 1) != (2 == (2 == 1))
(0 && 0 || 1) != (0 && (0 || 1))
this kinda makes me wonder about the other bitwise operators, although as far as I can tell there's no way to confirm their associativity (IIRC &|^ operations are nonassociative with themselves in the mathematical sense, similar to addition by itself)
-- Void ^{(talk|contribs)} 05:36, 11 January 2010 (UTC)

ok, and here's the funny part, so far my testing shows "," his a higer precendence that "]" but a lower precedence than "]" and a higher precedence than "++" "--", the two of which appear to have equal precedence to "[]"... and never mind variable evaluation.... it's like a sick round robin.
-- Void ^{(talk|contribs)} 06:37, 11 January 2010 (UTC)

ok, got it all figured out... the big issue was the two pass nature of LSL precedence... LSL is strictly pass by value, which apparently even applies to the stack... so variables are read onto the stack (in R2L order) and then all the operations are done.... the only major exception to this seems to be the comma separators within functions and lists, which apparently go into the stack in L2R order, per element. there is a minor hiccup in the difference between pre and post (in/de)crement operators, where they all have the same precedence, but the order of their action actually behaves differently... for sanity, the overall evaluation precedence is kept, and the action order can be documented on the respective page.

oh yeah, and for associativity in the previous comments read directionality.
-- Void ^{(talk|contribs)} 12:54, 28 September 2010 (UTC)

You are correct about both R2L and L2R aspects. The reason for it is that the LSL operators are backwards compared to all other bytecodes and assembly languages (LSO had it backwards). As you have discovered this has huge ramification for the order of execution (and was a bit of a headache for making the LSL-Mono compiler; as it had to honor the LSO backwards nature at the cost of performance). -- Strife ^{(talk|contribs)} 20:49, 28 September 2010 (UTC)