Don't click here unless you want to be banned.

LSL Wiki : value

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are ia360925.us.archive.org

value

In LSL, values are used and returned by operators and functions.

Each value has an associated type that constrains how it may be used (these constraints are purely in the compiler and not part of LSL). To convert one value type into another, a typecast is required. Typecasting a value may have irreversable effects to its value.

New values are created in scripts using literal expressions or by executing expressions containing operators or value-returning function calls. Values may be assigned to (or stored in) variables, retrieved from variables, used as operands in expressions, and result from applying operators. Values are also passed into function calls as parameters and returned from function calls.

Many, but not all, values can be represented with literal text in code. In the following example, the literal text representation of 5, "Hello", and <1, 2, 3> are all referred to as literal values.

integer x = 5;
string greeting = "Hello";
vector pos = <1, 2, 3>;

LSL has a limitation on the values that can be in a list.

Those curious as to how literals are parsed can take a look at the lex file.


script | variable | type
Comments [Hide comments/form]
Uh, why is it irrelevant? Value IS assigned meaning by operators.
-- EepQuirk (2005-09-14 01:49:14)
A value can exist regardless of operators.
-- BlindWanderer (2005-09-14 08:21:57)
No it can't. How does value GET into existance unless it is ASSIGNED meaning by something? Duh. Basic philosophy, BW...
-- EepQuirk (2005-09-19 12:09:35)
4; //it's valid it's got value but not asigned; it has inherint value
What was defining on this page was identifier.
-- BlindWanderer (2005-09-20 12:41:26)
I reworked the page. Readability could be improved, but the confusion between values and variables is hopefully cleared up.

TODO:

* Reference Literal, and probably move the stuff on literal values there.

* Talk about pass-by-value. A list is not copied when passed to a function - only the reference to the list is copied.

* Stay away from the value of money :)
-- ZenoConcord (2005-09-20 21:20:17)
oh no a list is copied when it is passed, we all wish it were pass by refrence, same with strings.
-- BlindWanderer (2005-09-20 23:03:19)
Well, there are no functions that cause side effects on lists, but that by itself does not mean that the list arguments are copied in entirety. After all, you can't tell whether the list is copied or not because there is no function that causes side effects.

It could be that only the *reference* to the list object is copied, although, because there are no side-effecting functions on lists, there would be no need to even copy the reference.

The only way you can tell whether lists are copied is by looking at the code, or doing careful time and/or memory tests. Do function calls with increasingly longer lists but always just pull off the first element so it should not matter how long the list is. Do a recursive call with a moderately large list and see how many calls can be made before memory fills up. Looks like someone did some measurements: List Push and Pop
-- ZenoConcord (2005-09-23 17:34:40)
ok, they are passed by refrence *but* a new copy of the list is generated. So it might as well by pass by value. Same with strings. strings and lists when they are in the stack are just pointers. But there is never more then one pointer pointing to a memory address.
-- BlindWanderer (2005-09-24 12:21:41)
BW, "4" only has value because YOU, the obsever, ASSIGN value to it (by counting up to it, relating it as a "number", seeing "4" "objects" in your mind, etc.
-- EepQuirk (2005-09-25 17:12:37)
Eep, thanks for adding some reasonable links. But please don't add anything about assigning meaning to constants, with a reference to assignment.

BW, as long as you don't mean the entire list (or string) is copied, then we are in agreement. Only the reference is copied. It is still pass-by-value, however, even if the values happen to be references. Java is the same. Here is good explanation: Does Java use pass by value or pass by reference semantics.... I believe Q/A section on the list page is incorrect.
-- ZenoConcord (2005-09-25 17:43:30)
*Ignores Eep*

In LSL when a funciton is called...
reserver space for return
4 bytes - Address of where to return to when function exits
Copy paramaters into stack
Reserver memory for functions local variables
Adjust stack zero
run function
set return value.
restore stack zero
return to address.

While these two are different in structure they work the same way, both result in two copies of a existing in memory.
string a;

me(string b)
{
    //hi;
}

default
{
    state_entry()
    {
        me(a);
    }
}

It's just a matter of when the copy is executed; but the data is copied in the same mannor in both cases.

string a;

me()
{
    string b = a;
    //hi;
}

default
{
    state_entry()
    {
        me();
    }
}

When ever a function or operator acts on a value, a copy of the value is returned or a pointer is returned to that copy.

Anyway it's not actualy important to know the mechanics of this, only that operators and functions never work with the original data, they work with copies.

string Ls1 = "temp"; //read string from bytecode into memory, push pointer (address of string) into stack. pop pointer from stack copy into memory space Ls1.
string Ls2 = Ls1; //read pointer in memory space Ls1, copy string into another part of the memory, push pointer (addess of copy of string) into stack. pop pointer from stack copy into memory space Ls2.

The same bytecodes that are used to copy values from one memory address to another are used to copy paramaters for calling functions.
-- BlindWanderer (2005-09-25 22:41:10)
Oh and keys and strings are the same datatype. They use the same copy functions, the same store functions. The only time they are treated different is when they are handled by operators or fed into lists. floats are the same way except they share thier handlers with integer. A vector is literaly just 3 floats; rotation, 4 floats.
-- BlindWanderer (2005-09-25 22:53:56)
This page is quite confusing. I think it would help most developers if near the top it said either "function parameters are pass-by-value" or "function parameters are pass-by-reference" or "function parameters are either, depending on their type as follows: ...".

It sounds like, from the discussion, that all parameters are pass by value. In fact, it almost sounds like all strings and lists are immutable, which is quite suprising. That would mean if L were a list that "L += [42]" would require the entire list to be copied...

Can anyone clarify these issues succinctly?
Q1: Are parameters pass-by-value or -reference?
Q2: Are lists and strings immutable?

It is easy enough to test though, for example, what does this script say?

foo(list l, integer a)
{
l += a;
}

default
{
state_entry()
{
list someNumbers = [23, 42];
foo(someNumbers, 97);
llSay(0, llDumpList2String(someNumbers, ", "));
}
}
-- 209.97.232.97 (2007-03-09 22:20:39)
Attach a comment to this page: