What's wrong with these declarations?

Hi,

I kept getting compile errors in the 3rd line of my script, as follows. Basically, I have declaring two vector variables, Open and Closed, and setting Cut to be the same as Closed at the start.

vector Closed = <0.0, 1.0, 0.0>;
vector Open = <0.0, 0.02, 0.0>;
vector Cut = Closed;

For the third line I tried:
vector Cut == Closed;

or
Vector Cut;
Cut = Closed;

or
Vector Cut;
Cut == Closed;

Every combination I could think of. In the end I gave up and simple declared Cut as:
vector Cut = <0.0, 1.0, 0.0>;

But, just to sastisfy my curiousity, and help me understand things better, why could I not set Cut to be equal to Closed?

Rock

LSL only allows a constant for an initialized variable in global scope (at the top level), and LSL does not support user-defined manifest constants, so you either have to use <0.0, 1.0, 0.0> or leave Cut undefined and initialize it in the state_entry() event for the default state.

Rock's initial version compiles and runs OK for me.

vector Closed = <0.0, 1.0, 0.0>;
vector Open = <0.0, 0.02, 0.0>;
vector Cut = Closed;

default
{
    touch_start(integer blah)
    {
        llOwnerSay((string) Cut);
    }
}

Confirmed. Works both in LSLEditor and in world. Rock, try throwing your code through lslint, it does a better job of defining the errors. Or if you haven't tried it yet, I would highly recommend LSLEditor which is free. It will check the syntax and point out not only the line but the specific spot in the line that the error is occuring. You can also test some scripts just as I did with yours without having to log in.

compiled in mono?

because I remember having that problem before (well similar) in that it wouldn't compile if there was any operations going on in the globals

That code shouldn't work. It's not legal LSL. It shouldn't be legal LSL. If it works, that's a bug. Yes, really.

Why?

Because Closed is not a constant, and treating a variable as a variable some places and a constant others is bad practice. If LL wants to *make* that work, they need to create real constants, for example:

constant vector Closed = <0.0,1.0,0.0>;
constant vector Open = <0.0, 0.02, 0.0>;
vector Cut = Closed;

[...]

default
{
state_entry()
{
Open = <1.0,0.0,0.0>; // syntax error;
Cut = <1.0,0.0,0.0>; // legal
}
}

As a bonus, unused constants should take ZERO space in the compiled code, so you could define a bunch of constants for common operations without worrying about it putting you over the memory limit.

I'd tried it with the server-side compiler for both LSL2 and Mono, plus dragged out an older viewer (1.18.something) to try the old viewer-side compiler, all three chewed on it happily.

All three continue to be unhappy with any assignments that are more complex than that.

[eta: finding this kind of assignment in scripts going back as far as 2004, so if it's a bug it's an institutionalized one.]

This should work no problem .. do things like this all the time.

Argent - Since LSL does not provide real constants we have to make due, in the end they are all variables for LSL. So if I write:

//Constants
string EMPTY_STR = "";
...
//End Constants

//Global Variables
string gName = EMPTY_STR;
...
//End Globals

As long as I am disciplined and never assign values to EMPTY_STR in my code, then in effect it is a constant.

Yep in MONO. I am sure though if you tried something like : vector cut = llGetPos(); that it wouldn't work. Probably what Viktoria was saying about more complex.

Yeah that, you can assign a global variable to another global, but no expressions. I'll bet that Strife could dig up the exact reason, but at a guess it was functionality that sneaked in for free to accommodate the built-in constants.

Yes, I know that. I do understand the technology... I wrote my first compiler around 1980, for the "Bloop" and "Floop" languages designed by Douglas Hofstadter for the book "Gödel, Escher, Bach".

My point is not that you can't use variables as constants, my point is that you shouldn't be able to use variables in places where the language definition *requires* constants. It opens up a whole new class of errors for people to make.

This certainly didn't used to be possible. And in the LSL compiler shipped in the open source client, you couldn't do this (at least as of the last time I worked on the code, and I haven't seen anything in the release notes about changing this).

The only time this makes sense is for an incrementally compiled language, where you can execute any code you want in the global scope at any time. If they were doing that, though, they'd let you write code like this:

// Initialize global list.
integer len;
list l;
for(len = 0; len < 10; len++) l += len;

This code would be executed at *compile time*, like a macro, leaving the compiled image containing the same code as if you'd written:

integer len = 10;
list l = [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 ];

On the other hand, adding a real constant mechanism to the language prevents those errors, and also allows the compiler to generate better code without actually requiring an optimization pass. It's a win-win situation.

The built-in constants are hard-coded into the compiler. You can see them in indra.l.

If they're not using the same compiler on the server as the one distributed under indra/lscript any more, they should remove it from the client. It's just going to cause confusion now.

Yes they are set in there, but the interesting part is what it does with them.

Again, this works with the 1.18 client side compiler too. For a common script example predating open source that uses this, dig up an old copy of Franimation and note the 'float standTime = standTimeDefault;' up in global space.

I'll have to do some looking around. I was under the impression that scripts are no longer compiled to byte code client side.
UPDATE: LSL is compiled client side & MONO is compiled server side as stated in this JIRA and confirmed by Periapse Linden:

http://jira.secondlife.com/browse/VWR-8827;jsessionid=196CD9E5920CBB85D5270FE9B14E35B8

I created a new script in inventory and had no choice for MONO as stated in the jira. Our test script still compiles in inventory as LSL and works when put in an object in world. It also works when it is compiled in world as LSL.

It is the lsl script engine in OpenSim that refuses to work with this, not in SL, Rock should have made that clear. The discussion is interesting though, nonetheless.

Front

oh i would have figured it'd die on assigning a function, but it also dies on simple math like 1+1 (was just making my life easier not precalculating the math)

I do see the point of what arget is getting at.... all variables are being treated as constant, or vice versa... which does open up a lot of weirdness... but out of curiosity, has anyone tried to reassign the value of a built in constant within a script?

That one does throw a syntax error.

I have code at least as old as late 2006 in which you could. I've done it quite often, especially to initialize global list elements. I often make dialog menus using a pattern that looks something like:

string APPLES_AND_BANANAS = "app and b";
string ORANGES = "oranges";
string PEACHES_AND_CREAM = "peach & c";
list MENU_CHOICES = [ APPLES_AND_BANANAS, ORANGES, PEACHES_AND_CREAM ];

Works fabulously. Has since I joined SL as far as I know.

At the time globals are initialized, other globals ARE constant. It's not until default/state_entry starts executing that there is the opportunity to change them. So I'm not sure it is all that inconsistent.