|
|
|
I have no problem with planning LSL3 but changes to LSL have to wait until after Mono ships. The Mono team is steadfast against making changes to LSL until it ships.
You are too generous Feynt, it was an afternoon to plan, an evening to drink, then back to work to implement. Maybe that was a bit too cruel. >.> Actually, I put up this jira in response to Periapse Linden's remarks at Friday's mono beta meeting. He indicated the mono team wanted to start a discussion of where to go next. Note that I added the part about the OSSL OOP. I talked to Tedd Maa last night about where OSSL was heading and the things they are planning sound very cool.
Every hour of work invested in the Mono VM brings us closer to being able to use a multitude of other source languages – very good languages.
Every hour of work spent on improving LSL brings us closer to a better LSL. Unless there are resources to pursue both directions, I think we'd leverage our resources better and get a better return on the former. Given what I have seen on both subjects? No reason to freeze LSL development... Everything I have read has stated that LL plans to continue maintaining and expanding on LSL, even while switching to Mono to open the door to adding new language posibilities... The last official word I read stated that even if other languages were brought in such as Python, Ruby, C#, or even Lua, that LSL would remain a useable language, the only change in that department would be a backend change, in how the LSL code was compiled, so that it would be able to be ran on the Mono VM... So why cut ourselves short by freezing further development? Especially when I haven't heard any info on how the change over is going to be handled to move from the existing VM to a Mono only system... Some have stated that they were going to do a re-compile on all scripts, but as mentioned else where, that would cause a very large number of scripts to loose stored data, others have said they were going to run the two VMs in tandem for a given period of time to help give people a chance to migrate data over, etc... So, personally, I would say calling for a freeze now would be kind of premature until more details are locked down and made public...
davie Zinner, there are always tradeoffs. Is it significantly faster to add new syntax and functions to LSL (LSL3) over adding support for new languages? LSL2 support exists NOW. C# support requires lots of consideration of what features might be dangerous. There is work on a mono sandbox that Babbage recently mentioned but how soon will that be ready for deployment in SL? WOuld it be faster to wait for that, or to add case/switch handling, etc., to the LSL syntax?
Damian McLeod, my understanding is that the current plan is to keep the LSL2 virtual machine around forever (more or less) because many scripts will simply not work right, for various reasons, if recompiled to mono. So... the question becomes: how soon do we want to move to a mono-only NEW programming environment? I vote for sooner, rather than later. Freeze LSL2 (except for a few features that might make sense if implemented over the next few months) and start working on extending/repairing the language with LSL3, which only works with the mono-enabled sims. It MAY be that the eventual goal is to make LSL3 into C# but it might be easier on scripters to do it one step at a time... I don't know if it's already been changed on the mono beta but if it hasn't even before languages such as c# are implemented (that already have this capability in theory) the limit on recursive if, when, etc... statements should be removed since at least in theory mono should be able to handle them better than lsl2. There are a million different things to add too such as switch statements which have already been mentioned and hopefully we won't have to wait for C to use them.
One thing I'd definitely like to see is a mono performance counter separate from the LSL performance counter.
I intend to convert every script I possibly can to mono once my simulator switches. If I have any data-store scripts, I'll leave them as LSL if I deem the contents useful enough. Long ago I switched to database backed http calls for storing stuff like visitor lists and product update IM notifiers. But, the NUMBER ONE REQUIREMENT for LSL3 should be a Type/Key/Value permanent data storage system. Primarily, we need Strings, Integers, and booleans. Booleans are very important here, because they use up so little space. 1K should be enough for just about any name/value combination I would propose list[value,value] llGet{Linked}Flash(list[key, key]), integer[used] llSet{Linked}Flash(stride-list[key, value,key, value] ), list[value,value] llGetPublicFlash(key object, list[key key]), and integer[free] llGetFreeFlash(key[special]). NULL_KEY gets local prim's free space, linkmate's key will return that prim's free space. Non-linkmates always return 0 for now Simple, unobtrusive, and very very useful for everything from prefs storage to exchanging data between multiple prims in an object or even multiple objects. The perfect posterchild for LSL3? (http_server would be nice too! I created a page for LSL3 a couple weeks ago on the wiki.
https://wiki.secondlife.com/wiki/LSL3  Kamilion, I would prefer any use of a special cache space to use a better syntax than the llList* functions.
Stryfe, I'll put a reference to your page on my mono bugs table page, and spam its existence in the usual places I irritate. Also, added a couple of comments in the discussion page. When you start adding new keywords and changing existing functionality it can't be fully backwards compatible.
Note change: Suggested LSL3 would be in C# syntax as per my suggestion on SLDEV
Going through the points in this proposal in turn:
1. case/switch statements could be implemented in LSL with the existing LSL bytecode, there's no reason that part has to be implemented in Mono. I could do that myself in the LSL compiler. 2. LSL2 and CIL use the same runtime routines, changes to things like llSetPrimitiveParams are not really a language issue and should be addressed in their own JIRA proposals. 3. Better string functions (llRegCmp, etc) are also runtime library rather than language issues. 4. The list handling functions in LSL are also in the runtime. Adding references to the language would be a significant change, almost as much work as designing a new language from scratch (I've designed a few over the past 30 years). 5. Genuine constants are a good idea, and should be implemented independently of the MONO effort: they could be added to indra.y withoutany impact on the code generator. 6. New data types: I've proposed a couple of these that would work in the framework of the LSL language. The best and most general one would be a hash... to avoid refernce problems this would need to be restricted to global scope. I am almost sure that this could be implemented in the existing LSL2 bytecode. 7. Objects are probably not a good idea for the scope of this problem, and it woudl probably be best to use an existing language to completely replace LSL: the syntax of "C" is not really well-adapted to object-oriented code. Something like Smalltalk or F-Script would be better, and allow a tighter implementation.
So while these are all useful ideas, I really don't think that these should be described as "MONO-related" extensions. Most of them are either things that are outside the scope of CIL-vs-LSL2, could be implemented in the existing indra.y, or are sufficiently complex that they're not really good candidates for an interim solution. Implementing constants could be tricky, while you could inline the values this is a bad solution for string, vector and rotation constants. They could be stored as global but then you would have extra overhead. A better solution would be to add a new section and LSO bytecodes to the VM. If you made the bytecode just a get a value at a constant address you could introduce some interesting possibilities for optimization. You wouldn't necessarily need a section for the constants, if you used pointers based on pure script offset you could put them anywhere, including in the bytecode section. By not having a section you wouldn't need to add a new pointer to script header and you could add the functionality without having to increment the script version.
CONST, integer pointer What is your response to the idea of just redoing LSL' s functionality in C# and calling it LSL3, then carefully unlocking features of C# to "add" new features to LSL3? Seems to me that that this could probably be done before a sandbox/bye-code verifier could be completed, and give script-writers a feel for any changes that will be due to moving to something like C#.
As far as adding features in LSL2 goes, I don't see a reason to, except concerning specific functions like adding "glow" to llSetPrimitiveParams and the like. I'm with Babbage (as I understand it) that I'd rather see everyone migrate to new languages. I just think the migration has to be slow. Adding a "Slang"-like solution to C# (gogle "Slang" and "Squeak Smalltalk") allows people to transition to a better language while allowing Babbage and company to add new features slowly and safely even before the safety checks are fully in place. I don't think it's meaningful to talk about "redoing LSL's functionality in C#". LSL is not a subset of C or C#, it is a unique and distinct language from either. There's no savings from writing a compiler for some kind of subset of C# that happens to overlap LSL, because you WOULD have to write a new compiler for a C# subset, and then switching from that compiler to C#. It would be more work to do that than to simply write directly in C# can call the LSL2 runtime. Creating a new C#-subset-that's-like-LSL is more work for less benefit than extending LSL ... which as already noted generates both LSL2 and CIL code from the same parser.
Many of the proposals listed here are improvements to the common LSL2/CIL runtime. Regular expression functions are runtime features, not language features. Additional parameters are runtime features. Additional communication mechanisms between scripts are runtime features. Well, I've never created a compiler (or even a subset of one) in my life, so I was just making some bad assumptions about what would be easier, I guess.
Regular expressions could be a language feature if a new type was created for them (it would allow for them to be compiled, making the scripts faster). Javascript has regex literals.
Javascript and Perl have regex literals, but you don't need regex literals to have compiled regular expressions... the compiler can just as easily notice that a string literal is used in a regular expression context.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
Mono release: Freeze [mostly or totally] LSL2 development where it is now and start adding new features and syntax in a mono-VM-only, LSL3 language, compatible with C# syntax
... Stored key names ending in _public are accessible via llGetPublicFlash. Passing a list containing only NULL_KEY will return a list of keys_public. I am aware of the internationalization issues, but considering the LSL function names are in english and I don't see that changing anytime soon, I doubt '_public' would be too much of a problem.
Why bother when Mono will eventually support proper languages which support all of these things and more? I'd rather use Python, which does all of these and is easier to read and write, than LSL which from the beginning was a flawed language (honestly, a day to plan and a day to implement? >.> )