When designing Phlox grammar and semantics we wanted to offer the highest compatibility with the majority of scripts that are already in existence. Most of these scripts have their origin outside of InWorldz and follow strict typing rules.
Somewhere along the line in OpenSim’s design, the LSL types were coded in such a way that just about any type was automatically convertible to any other type. We call this implicit type casting, or implicit conversion. Some types should be able to be implicitly promoted to other types. A good example is an integer to a float.
float f = 1;
We expect that since no loss of information will occur, and both types are numeric that this code will compile and run as expected which it does under the phlox engine with no warning.
During testing we found a small minority of scripts that were relying on other implicit casts that were not valid for LSL. These include “anything to string” and “anything to list”. The following will compile on our old script engine, but not in SL or on Phlox:
llSay(0, “hello!” + [integer expression]);
This leads us to why strictly typed languages can help in certain situations. For example, what would a beginner scripter expect from the following:
llSay(0, “1” + 2);
To a beginner this would look very ambiguous. Is the answer “3” 3 or “12”. That depends on the rules of the language, but should never have compiled in the first place without a cast:
llSay(0, “1” + (string)2);
That makes it clear we’re performing a string concatenation and not addition. Some languages, like PHP, solve this problem by having different operators for string concatenation vs arithmetic. LSL does not and so relies on semantic rules to try and prevent situations like this.
Good static typing also prevents passing the wrong parameters to functions:
f (string s, list l) ..
Under the current script engine, ms will be implicitly converted to a list and passed to the function. In this case the author probably meant to use msl. This is an actual case we found when testing scripts. Variable names have been changed to protect the innocent.
Thus far the vast majority of scripts have not been affected by this issue. If you scripts were created in SL and ported over, or run both here and in SL, then the chances of being affected by this incompatibility are very slim. If your scripts were written completely in InWorldz I recommend that you test them on the InWorldz sandboxes (which now are running Phlox) or the beta grid. The majority of scripts are up and running with one or two casts put in.
We’re choosing to move forward here because I don’t see the point in having a statically typed language that has very weak typing rules. That is just making people write out typenames with no purpose.
InWorldz has gathered some of our talented scripters together to help in this transition and to find any other problems with the script engine during the test rollout. If you have any questions or issues with scripts the Phlox Task Force is here to help.