~-1 * 10 == 9

just when I think I have a handle on LSL.....

(~-1 * 10) == 9 <-- wait, HUH !?!
~(-1 * 10) == 9 <-- this might be how it's actually parsing it
~-(1 * 10) == 9 <-- I suspect this is how it's being handled

(~-1) * 10 == 0 <-- here's what we expected
~(-1) * 10 == 0 <-- this seems to force the issue
(10 * ~-1) == 0 <-- ooh look that gets it too

someone? anyone? please explain why negation appears to have a lower precedence than multiplication? yet a equal one than bitwise-NOT

(if your curious ~- subtracts 1 from the number -~ would add 1)

ETA: I'm thinking compiler bug

Tried in both Mono and LSL compilers?

yup, same result either compile

Yeah, precedence should be a front-end parser function.

I've noticed that in LSL, as opposed to other languages, I tend to parenthesize obsessively. Never took the time to nail down exactly what was making me uneasy, tho ... this could be it.
.

well overall the whole lsl compile order is goofy... variables are evaluated right to left, with some exceptions which throw a lot of things out of whack

Because it's not negation, it's a negative integer constant. If you want negation, add a space or parentheses.

It doesn't. What you're seeing is that bitwise operations have a lower precedence than arithmetic ops. Also:

"~-" is not an operator, and what it means depends on the rest of the expression.

By the rules of twos-complement arithmetic there is no difference between "-1 * 10)" and "1 * 10)".

You can check the actual parser, it's still in the open source client, but I'm pretty sure that's what you're seeing, from what I remember of the code. I fixed a bug in that part of the parser some years back, but haven't looked at the code since then.

I suspect there is a bug there, since I would have expected "~(-1) * 10" to produce the same result as "~ -1 * 10"... but I would ALWAYS recommend fully parenthesizing any expression that involves operators other than +, -, *, and /.

it was originally found as ~-X * 10, where X = 1, so that should treat as negation....

I'm thinking the compiler looks at the - operator, sees that that the next leftward action isn't a variable or number, so drops down and does the multiplication before coming back up and finishing...

@Argent:
so far testing has shown unary operators are all higher precedence than multiplication... although inventing tests for them is... interesting, especially for negation and logical not. (~ is definitely higher)

Nothing so simple. It uses a LALR(1) parser that maintains a stack of pending operators and potential "next state" parsings to create an explicit parse tree. The code generator then walks the parse tree and outputs CIL or LSO opcodes. The same parser and parse tree contains code for the syntax coloring in the script editor.

You do NOT need to perform tests to figure this out. The code is available to you in the client.

testing is probably faster than me finding it, and lets me spot difference between LSO and MONO... but your point is well taken... I probably should dig around in there

EDIT
removed funny typo of SLO =)

I think it would be faster (and less eyestrain) testing it than trying to sort it out from the source code. <.<

That's what I mostly do these days. My connection sucks too much for me to get inworld.

http://svn.secondlife.com/trac/linden/browser/trunk/indra/lscript/lscript_compile/indra.l
http://svn.secondlife.com/trac/linden/browser/trunk/indra/lscript/lscript_compile/indra.y
http://svn.secondlife.com/trac/linden/browser/trunk/indra/lscript/lscript_compile/lscript_tree.cpp
http://svn.secondlife.com/trac/linden/browser/trunk/indra/lscript/lscript_execute/lscript_execute.cpp

The typecast compatibility tables are stored in a different file (both implicit and explicit).


I don't like leaving it to the compiler to work it out either. Sure the expressions get noisy with so many parentheses but they execute the way we intend. In an editor with parentheses match highlighting it really isn't all that bad.

Um, no. It's a yacc grammar. Very straightforward.

I suspect there's a shift-reduce conflict between left- and right-associative operators somewhere in the grammar.

"-" is the only operator I've seen it with, the other unary's behave as expected from testing. so I'm thinking it's in the decision of what kind of operation "-" is doing. subtraction or negation.