LSL Switch Statement

From Second Life Wiki
Jump to: navigation, search

This article is a feature request

The ability to use something like the following:

Switch (variable) 
    case condition 1:
        Do something;
    case condition 2:
        Do something;
        Do something;

Note: Isn't LSL all server-side? I don't think this can be implemented in the client. - Ihavegot Wood

LSL is run on the server yes, but the compiler is in the client. LSO wasn't designed with switch statements in mind so some changes to the VM would be required, just wait for Mono. Strife Onizuka

This is not entirely accurate ... LSO has branch instructions (aka GOTO) which is all that is needed to implement switch constructs and the break and continue statements. Basically, it's just an issue of adding these statements to the compiler and ensuring the code generator emits the proper LSO instructions. Besides updating the grammar itself, I'd personally like to see the use of ANTLR (see [1]) over the current Flex/Yacc/Bison implementation. Provided that LL isn't already in the process of implementing this, I would not be adverse to doing so myself. --Num Skall 12:07, 18 April 2007 (PDT)

The issue is that LSL is a stack based language, the act of doing a conditional jump pops the condition off the stack, unless something special was done for switch statements there would be no performance improvement over complex conditional structures. If you are willing to write the code to implement this, the LSL compiler is open source. Of course when the LSL is ported to Mono we won't have to use LSL to write scripts for SL. I'm still trying to decide if I'm going to use Managed C++ or C#. Either way I get switch statements without LL having to do anything. -- Strife Onizuka 18:51, 18 April 2007 (PDT)
So? The issue isn't performance improvement but, rather, simplicity and readability of the LSL code. As for LSO being stack based, that's also a non-issue. My current projects are exactly like that too. Besides, having break and continue statements are the real benefit here. Think of how that would improve looping constructs. Properly done, the resulting object code efficiency will be the same. I'll get the source installed and see just how much is going to be involved. The first step will be converting to use of ANTLR to get the benefits of a full LRL rescursive-decent parser (makes code generation from the parse tree oh so much easier). It also generates the Lexical Analyzer from the same grammar file. Win-win. -- Num Skall 12:18, 20 April 2007 (PDT)