Global Variable Assignment Oddness

I'm working on a grammar for an outside-of-SL LSL parser, so I've been running lots of little testcases. I just noticed some serious strangeness when assigning values to local variables.

integer i = 10-9; // compiles
integer j = 10 - 9; // syntax error

All other arithmetic operations seem to fail 'correctly' on the first example, i.e.

integer i = 10+9;

throws a syntax error. If the value of i above is displayed with an llSay() in state_entry(), it's 10. Anybody capable of shedding light on this?

Known bug/issue -- the parser has a problem with the hyphen (AKA minus, negative) token. See here for more info:

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

(It looks like the reverse of your sample code, but... check it out anyway).

Along with the hyphenation bug, you can't do expressions in global assignments. Only constants can be assigned to globals. For example, what would you want the system to do for this:

list someList=[1,2,3,4,5];
integer foo=llListFindList(someList,[2,3]);

default {
    state_entry() {
        someList = [3,4,5,6,7];
    }
}

Totally fabricated off the top of my head, but the question is, when woul dyou have that llListFindList() call executed? What would the scope be? Anyway, the point is, you can only assign a value to a global, and that's only for convenience. Aside from the hyphen parsing bug (which you should not implement ), no expressions are allowed in globals.

By the way, I know that Andrew Linden posted the lex (heh) file for LSL somewhere in the forums...

I'm familiar with the minus-sign known bug: I'm pretty sure this isn't related, except for in a general boy-the-parser-sorta-blows-on-global-variable-assignments sense.

Lex, if Andrew did post a LEX file to the forums at any point, I wasn't able to find it. A link would be most welcome.

This is 'as intended' - you cannot dynamically assign globals in their initialisation. (There is good reasons for this.)

If you want to use functions (or in this case, arithmetic) in your globals - make an init function and assign your globals values there.

-Adam

I'm aware that expression assignment for globals at the point of declaration is prohibited. What my post points out, and what I'm curious about, is the inconsistent behavior of the LSL parser during global assignment when the minus operator is used as I did above.

Even if we assume that "10-9" is being split into two tokens, i.e. the "-" is being treated as a unary minus informing the 9, this shouldn't parse.

My guess is that they simply screwed up their parser. In C-like languages (SL is written in C++, I think) if you use atoi() to convert a string to a number, it'll convert up to the first non-numeric character and return the results. Their parser is probably just not good enough (perhaps due to the dash bug?) to detect that "10-9" isn't a valid number... so it converts it to one, and all is well. The -9 is probably just completely ignored.

As far as the lex file... I'm not sure. I _know_ I read something... a "standing offer" from one of the developer lindens that anyone who thought they could write a better parser was welcome to take the LEX file and do so. I believe I even skimmed a copy of the file. I can't find it either though... aha, it was Cory, here's the offer:

/3/93/29014/1.html

look for "yacc". The offer is that he'll give the files to anyone who'll write an optimizing compiler... but I imagine that, if they're that free with the parser files, they may give them to you to play with an offline compiler...

That's an interesting guess, and sounds pretty plausible. IIRC, typical standard libraries will implement atoi() to return 0 in case of an error (illegal chars, etc)... might be interesting to check the value of the thing in LSL at run-time, to see if it's 10, or 0.

No, they typically return the converted value up until the first illegal character. "lkasdjf" becomes 0, but "10alkdsjf" becomes 10. Try it :)

Now LL have published the actual lex and yacc files for LSL you can see that they mess up numeric constants in the lexer. They define a lex macro of [-]?[0-9] for digits and then use that in the rules for picking up number constants the simplest of which is

{D}+ { yylval.ival = strtoul(yytext, NULL, 10); return(INTEGER_CONSTANT); }

So this would match "10-2" as well as garbage like "-9-3-2-2" but not "--2" which produces an compile error because each - has to be followed by one digit.

This differs from traditional practice in C-ish langauges which is to not have any special lexing for negative number constants at all and to sort it out in the parser - the reason being that binary - and + operators must bind tighter than the equivalent unary operators. LSL has problem with "10 -2" for this reason - although both numbers lex properly, they produce to numeric constants which makes no sense in an expression. That should lex as NUM MINUS NUM instead.

Oh well. I could suggest LL fix their parser, but when you do that you risk introducing subtle erorrs in existing scripts so I guess we're stuck with it.

If they fixed the parser it would only effect bytecode generation. It would not effect already compiled scripts.

Bugs should be fixed regardless if they break existing scripts. You need a strong foundation for a language you can't have known bugs.