LSL/OSSL were and are responsible for imparting a great deal of the interaction magic which has made SL and Opensim be what they are today.  However, the language (they really are the same, just with a few different command sets)  is hobbled in a few ways which really prevent it from moving past the stage of a toy language and into the realm of a useful language which could be used to develop serious functionality.  

Additionally, the current way LSL/OSSL is structured, it is strictly bound to platforms very much like SL/Opensim, meaning that there is a catch-22 of adoption.  Fewer users mean fewer scripters which means fewer things done with the language that inspire new users to join.  

As I shift my focus to OHM (which will also need a scripting language), I’ve been designing a new hypothetical scripting language based very heavily on LSL that solves some of these problems and a few more.  I’m calling it Leslie (LSL-Evolved).

Here’s how Leslie differs from LSL:

1. All platform-specific commands are stripped from the command set.  Leslie doesn’t implicitly know about or care about regions, agents, etc.  This not only makes Leslie easier to learn, it makes it far more portable to other contexts.
2. The addition of a command module add-in system and commands to detect the presence of modules.  Platform-specific functionality can be mixed back into scripts through this feature, as well as novel functionality provided by other modules.
3. Commands to handle the execution of the script, such as the ability to kill the script, or start another script included in the object.  The Leslie model does not assume that all scripts are automatically running, and these commands allow for a much more intelligent use of system resources, provides for compartmentalized code and adaptive behavior based on modules present in the environment.
4. Boolean variable type to replace the cute but ultimately badly designed use of the integer type for boolean operations.
5. An external template-based structured data-type similar to flat JSON.  This frees programmers from having to rely on strided lists for any kind of complex data representation.  It also allows Leslie to have struct-like data but without resorting to dot notation and maintains the asynchronous data and event model LSL already has.

These differences are designed to make Leslie portable, expressive, and useful to professional programmers while retaining much of what makes LSL already work.  The result for environments like SL/OS would be increased functionality, better memory footprint, and utilizations of the platform which simply haven’t been feasible up to this point.  I plan on documenting Leslie more in the future, especially the struct model which requires more explanation. This is by no means a finalized design, and I would love feedback from the community on Leslie.