On occasion I plan to discuss aspects of LSL language design, even though the practice may recognizably be futile. Creating a better language has already been demonstrated not to be on Linden Lab’s priority list. Yes, occasionally they’ll add a new function or two or three, and they’ll deprecate or remove outdated functions, but the syntax and semantics of the language are another matter entirely.
Take a look in the Jira, and you will see scads of complaints concerning perceived malfunctions of functionality. True, some of them are genuinely troublesome, as others are minor and esoteric.
I would hope nevertheless that the world would not stop trying to improve itself just because LL hasn’t diverted 100 percent of its attention to someone’s pet perceived bug.
Here’s one of my pet minor annoyances, which, like the tolerance of a sore tooth, only becomes more exasperating with time. Let’s consider the following example for a conditional assignment in LSL:
[lsl]
integer X;
if (condition)
X = 11;
else
X = 3;
[/lsl]
…and that doesn’t even include room for the optional braces.
To assign one value using a conditional statement, we’re actually writing X in three statements and five lines of code for what should be one trivial, unified, nearly atomic operation. In many languages, such as standard Pascal, this syntax is unavoidable.
Even when it is necessary, I have always found this pattern verbose and redundant. Instructors, however, will teach that this is the only true and proper way of writing this logic, as it is supposedly the most readable and most maintainable form. I believe this is not necessarily the case, and that this is just one reason why the Pascal language never really caught on.
(Yes, Pascal was never meant to be more than a teaching language. But then, neither was the original form of BASIC, and we all know what happened to that.)
I prefer other forms that attempt to balance readability with writability. One way to be a bit more concise in LSL is to declare and initialize within the same statement, afterwards performing a reassignment for the exception:
[lsl]
integer X = 11;
if (!condition) X = 3;
[/lsl]
Or, of course, depending on the expected distribution of the results of the condition:
[lsl]
integer X = 3;
if (condition) X = 11;
[/lsl]
So instead of using X in three statements, we’re down to two. Having come from an assembly-language background, I find this to be a reasonable method of handling a conditional expression, given the allowable syntax of variable declaration and assignment in LSL. I have read arguments saying that reassignment is inefficient and should be avoided at most, if not all, costs. But such a decision really depends on the context.
BTW, as a matter of style, you’ll notice I have lined up the left-hand side (LHS) of the equation whenever it makes the code prettier, and have written the IF statement on one line. I also reject the current fad of insisting that all IF/ELSE statements require braces for single statements after the condition. I will, however, agree that I may have developed a slightly more distinctive style than those advised by people who think they’re the only ones who are right.
Still, a conditional assignment ought to be more integrated yet less verbose. It would really be great if the LHS could be referenced only once, thereby emphasizing the unified nature of the operation. Also, I’d only have one typo to contend with, not possibly three.
The Ternary Solution
The C language was known from its original publication to be more writable–i.e, concise enough for its concepts–than most of its contemporaries, with the certain exception of APL, but let’s not go there. Its convenient syntax for auto-increment and side-effect assignment, for instance–both of which can be found in LSL–took some getting used to. Well, I got used to autoincrements rather quickly. Today, these innovations are expected in the syntax of C-family languages, though their adoption in production code even today is controversial: see Douglas Crockford’s arguments against using these two very techniques in JavaScript.
A welcome syntax in C was designed expressly for conditional assignment. It is a ternary operator (?:), effectively a concise if-then-else operation that returns a result, and is best used for clearly understandable, one-line expressions. Compare this pseudocode:
[lsl]
IF condition THEN return true_expression ELSE return false_expression
[/lsl]
with the syntax of the ternary operation:
[lsl]
condition ? true_expression : false_expression
[/lsl]
Outside of the initializtion of the condition, our example could be written, and really ought to be allowed to be written, in LSL as:
[lsl]
integer X = condition ? 11 : 3;
[/lsl]
The trivial operation that took five lines in the original example now takes only one. Now I can sleep at night. Except that I can’t, because in LSL I cannot express such a simple concept in this simple manner.
This operator is found at least in C/C++, Java, PHP, and JavaScript, and, from what I read, has recently been added using different syntax to Python and Visual Basic. Let me say this again: a conditional expression syntax now exists in Visual Basic, but not in LSL.
The addition of the ternary operator to the LSL syntax would be backwards-compatible. No new language is created except for philosophy majors. Existing programs would not break. It is an elegant, concise syntax that is also very readable.
A Jira ticket on this has already been submitted as MISC-271. Unfortunately, only six people have voted for it since its creation in June 2007. Hay, feel free to add your vote!
Update
I have encountered a syntax which, I believe, supplies a mechanism in keeping with the spirit of conditional expressions. It is slightly less readable than the classic ternary operator, but it requires no modification to LSL. That being the case: though I will keep my vote for this issue in place, I will no longer recommend the ticket to others.