I tend to say that working with LSL makes me want to murder kittens, that might not be very accurate (it’s more like killing babies than kittens) but this week after a little chat with Ash I figured out I can either keep complaining about it forever (since the project of implementing C# or some variation of it got shelved), or do something about it to make my life, and potentially other people’s too, easier. I gave it a working title “Slurp” (yes, really), and got to work to produce a proof of concept demo/prototype of it.
What I totally want to do:
- Add a dictionary or dict variable type to store key-value paired data (associative array if you wish).
- Make accessing list and dict elements easy with variable_name[key] common in all modern programming languages.
- Make variable converting in function calls automatic – yes, I really want to just print out an integer via llOwnerSay() to debug my code – I just think we can all give coders some more benefit of a doubt and assume they are not complete idiots and know what they are doing.
- Add ability to call functions with less arguments than there are required (rest gets filled with their respective null values, handy with llListen() and the likes).
- Add ability to define events with less or no arguments at all (more often than not you don’t even use the detected_num in touch events and what have you), and if you do define them – not having to declare their types (not like you can choose what type they can be anyway).
- Quality of life: state keyword no longer required when declaring a state (it already works this way for default, which just creates inconsistence IMHO).
- Quality of life: rename state_entry event to just entry, because I can!
- Quality of life: vector being declarable with less than 3 parameters (you often need only two when dealing with llSetPrimitiveParams() and the likes), or no parameters at all making <> equal a null vector. Note: rotation will still require a set of four.
Things I wanted to do but will probably abandon:
- Renaming linden functions. I don’t like them being in global namespace and I don’t like how they are camelCase when the rest of the language seems to utilize underscores, but for the sake of not having people re-learn everything about LSL I will most likely keep the function names the same.
- Loosely typed variables – lack of strong typing can create issues when declaring custom functions and further development for me – not worth the effort.
In the unforeseen future:
- Ability to nest dictionaries and lists (possibly not lists but a nest-able array alternative).
- JSON parser, fuck yeah.
I’ll need to write my compiler from scratch (the idea behind writing a prototype was to actually learn how to do it properly and figure out what problems I’ll face), so at this point nothing is set in stone. Also, if you have an idea for a name let me know! “Slurp” is a nice name, because it has “SL” in it and all, but I don’t think it will stick ;).