📃 SLua Alpha

some ideas on how it could work: Required scripts are saved as a different type of script: modules, with a new compiler option: compile to "SLua scriopt" or to "Slua module". Modules are executed when required and return a value, with a return statement, for instance a table with functions and constants. Scripts call modules as myModule = require("Module name") , the returned value is assigned to the variable myModule , using the script's memory space. The module must be in the object contents with the script that requires it. If the module is not in the object, its running state is disabled, or it doesn't return a value, require() will return nil. Once it returns, the module is removed from memory and its variables are garbage-collected. Modules are executed synchronously, the main script is paused until the module returns. Modules don't receive events, any events that arrive while the module is executing are queued in the main script. Modules can't require other modules, only scripts can use require() .

Traditional LSL requires bitwise operators quite often: event parameters ( changed ), function call flags ( llRezObjectWithParams ), ... Lua 5.3 introduced native bitwise operators: https://www.lua.org/manual/5.3/manual.html#3.4.2 Having these usable in SLua would be a significant quality-of-life improvement in the face of Luau's bit32 library, though the library does still include other very useful features like btest , replace , etc. The library should stay regardless. To be fair, Luau's reasoning for not including bitwise operators is decent, but LSL context adds quite a heavy weight on this decision. I don't know the work that would go into implementing these operators, but hopefully they can be implemented in such a way that makes use of the same VM built-ins as the bit32 library to avoid any performance penalties.

Currently there are surely a lot of little parity problems. These are just some that I've noticed so far- local a = {1, 2, 3, 4} local b = {1, 2, nil, 4} local c = {1, 2, d = 3, 4} ll.OwnerSay(`a {#a} `) ll.OwnerSay(`b {#b} `) ll.OwnerSay(`c {#c} `) A and B will return 4, but C will return 3. Getting the length of a table with dictionary elements requires looping thru the entire table with pairs() each time, requiring a cludgy metamethod to have it work how one would 'expect', when just a table.len() would be useful. local Tbl = {} Tbl.__index = Tbl Tbl.__len = function(len) local incr = 0 for _ in pairs(len) do incr = incr + 1 end return incr end Likewise, list concatenation is a major thing in SL, allowing one to build up lists for llSetLinkPrimitiveParams for instance to save on function calls. This is entirely impossible in Lua with merging even two tables requiring your own function, or another cludge, to say nothing of matching the functionality of SL where multiple lists can be strung together easily- Table. __concat = function(a, b) if type(b) == "table" then for _, v in ipairs(b) do a[#a+1]=v end else a[#a+1]=b end return a end } As these are probably minor, basic functions that would get a lot of use, I feel like small things like this should start being added to the language, to prevent them from needing to be created in every script itself. The performance would also be higher if implemented in C on top of that. Lua is advertised as being an extremely tiny language, but that can be a little detrimental when we have to make even basic helper functions ourselves in our limited 64kb memory.

Tokens are --[=[ ]=] , doesn't highlight correctly, but saves fine. --[=[ Changed event handler https://wiki.secondlife.com/wiki/Changed @param change number -- bit field of CHANGED_* flags ]=] function changed(change: number) ll.OwnerSay(`change called with {change}`) end https://eryn.io/moonwave/docs/TagList http://lua-users.org/wiki/StringsTutorial (see nesting quotes section)

Currently, when scripting in Luau, indexing of tables does not match between Luau functions and ll. functions. For example, the following return the same values: str = ll.List2String(List,2) and str = List[3] This isn't exactly a bug, both are functioning 'correctly', but it's going to cause some issues. Is there a reasonable solution to this?