Operator Precendence in LSL

ok, wasted a lil time, and built tests for all the operators precedence... which may contain some errors as I'm a bit sleep deprived at the moment... so if you catch any, let me know


cut and paste into notepad or similar fixed width font window if you can't see php tags (or you could follow the link in my sig to be able to see php tags)

Operator |Associativity
+--------+-----------------+
| ()     | Inner to Outer  |
| []     | Right to Left   |
+--------+-----------------+
| ,      | Left to Right*  |
+--------+-----------------+
| ++     | Right to Left   |
| --     |                 |
+--------+-----------------+
| (type) | Right to Left   |
| ~      |                 |
| !      |                 |
| -      |                 |
+--------+-----------------+
| *      | Left to Right   |
| /      |                 |
| %      |                 |
+--------+-----------------+
| +      | Left to Right   |
| -      |                 |
+--------+-----------------+
| <<     | Left to Right   |
| >>     |                 |
+--------+-----------------+
| >      | Left to Right   |
| >=     |                 |
| <      |                 |
| <=     |                 |
+--------+-----------------+
| ==     | Left to Right   |
| !=     |                 |
+--------+-----------------+
| &      | Left to Right?  |
+--------+-----------------+
| ^      | Left to Right?  |
+--------+-----------------+
| |      | Left to Right?  |
+--------+-----------------+
| &&     | Left to Right   |
| ||     |                 |
+--------+-----------------+
| =      | Right to Left   |
| *=     |                 |
| /=     |                 |
| %=     |                 |
| +=     |                 |
| -=     |                 |
+--------+-----------------+

comma and assigments appear to be special cases...

comma obeys inner/outer rules within brackets/parentheses, but overrides them when outside, effectively promoting anything to the left of one over the right (similar to how parentheses promote inner over outer)

assignments demote anything left of them, until they hit a comma or the inside of a bracket/parentheses.

surprisingly, whether increment/decrement is used pre or post fix, they seem to be the same precedence.

if you find an error, just post the equation that demonstrates it.

ETA:
for those that don't know, Associativity is the direction operations of that precedence are done in, should there be more than 1 in the statement.

Is new? better? different? from what we have:
http://lslwiki.net/lslwiki/wakka.php?wakka=operators

better AND different (although I suppose I need to include the "dot" selector) though similar

I've pretty thoroughly tested precedence to make some changes and included the operators associativity (which direction those operations are done in).

for instance && and || are confirmed equal precedence, left to right execution
(0 && 0 || 1) == TRUE
(1 || 0 && 0) == FALSE

parentheses/Brackets have a backwards associativity than expected for same level items and commas are crazy powerful compared to normal C conventions.

I still don't have variable evaluation in there... but it's gotta be below the level of comma, right to left, but I can't be sure if it's before or after increment/decrement (haven't thought of a good test for that.)

Oh I see what you mean. When there is ambiguity in operator precedence, the operators are executed left to right. However when the operators are executed, the right hand operand is executed first. God, is that confusing.

This should demonstrate the execution order of the operands and implying the order in which the operators are being executed.

integer V(a, b){llOwnerSay(a); return b;}

default{
    state_entry(){
        llOwnerSay((string)(V("a", 0) && V("b", 0) || V("c", 1)));
        //b
        //a
        //c
        //1
        llOwnerSay((string)(V("a", 1) || V("b", 0) && V("c", 1)));
        //b
        //a
        //c
        //0
    }
}

I think (though I'm not sure yet) that all variables are evaluated in RtL at some precedence above braces, but below or equal to increment/decremnt.... but there's a round robin there I can't figure out...

The associativity at work with single-operand operators is a different type then that of the double-operand infix operators. The associativity of the outfix (lets call it) operators are even more different; as one is unary "expression)" and the other has an optional operand "[] or [comma separated items]".

The list is also missing the member access operator aka "dot operator".

----

I'm not considering the use of parentheses in flow control statements and function calls as they are part of the syntax and not optional.

dot is in my updated list that I'm compiling notes for, as are spaces for function and variable evaluation... I was tempted to throw in test operators (like if/while/for) jump, and ";" too... since it'd give some context for the evaluation precedences. decided not to update the working page till I get somewhere with that.

so far I've got "." above in/decrement and variable evaluation (since it's a selector) and below "," (with it's funky rules of higher outside braces, lower inside) but the tests are getting fuzzy after that....