Question about Mono and LSL ...

I have seen the discussion about Mono by Babbage Linden. From what I see there, it replaces the current Virtual Machine with a new VM that is much faster.

I also see lots of people say that there is no reason to complain about LSL, because Mono is coming (please don't flame that statement .

My understanding is that LSL and Mono are not the same thing at all. LSL compiles to a VM code. Even if Mono arrived today, LSL would be exactly the same (but execution would be faster, which is great). Am I confused?

I see what you are saying, And I'm not entirely sure this is correct, but I believe LSL will still be there for backward compatibility, however once MONO arrives, you will be able to script directly in it's native tongue, which is C#/.NET.

I think there has been some hope that we will be able to use other languages but as far as my understanding goes we will still be stuck with LSL, only it will supposedly be considerably quicker

It depends a bit on whether LL keep the compile process at the viewer as it is now.

If they do, I would think that any number of smart, energetic and resourceful developers will give us a variety of ways of generating mono (.net) byte code.

I think Babbage was talking about some process of injecting code that would allow rapid context switching between scripts and infallible serializing for sim crossings and taking to inventories. Hopefully that will happen at the server and the compilation will happen on the client.

ive heard in many town halls that we will still use lsl, its just a backend thing to speed up processing


course i wouldnt hold your breath, its been what? almost to over a year since they announced this vaporware...

Everything I've heard is that LSL is the language, it just would be run under the Mono engine at least initially.

The schedule for any of this seems pretty open ended though.

If Mono were to be considered to have a "native language", it would be IL bytecode. C# is simply the most commonly used language.

In the video that I saw, they did a demo of compiling regular LSL to Mono IL, and it ran a great deal faster as would be expected. That makes me think that there is every reason to believe that backward compatibility for LSL is a very high priority and is being provided for.

If the LSL code is already compiled on the client, couldn't anybody (with the right skills) invent a different language that compiles to the current LSL VM, and upload that?

Or how about a pre-processor, that takes some language in and spits out LSL. that's how C++ started...as a pre-processor for C. That's the ticket...LSL++

Add arrays, easier strings and lists, maybe a better list implementation...

I'm agreeing that I think LSL is still going to be the language provided. I am however hoping that with Mono we'll see more C-like constructs added, possibly even structs (kind-of objects). I'm not sure a full-blown object-oriented language is what LSL needs though, the ability to maybe take a key you know is an object and attempt to directly manipulate it (if you have permission) would be cool, e.g:

self.setPos(newPosition) or child.setPos(newPosition)

But mostly things like arrays, and maybe pointers (if they implemented them safely enough of course).

From what I had understood at the time of the article from Babbage, Mono is just a different server-side VM to run scripts on... and it should even allow sending compiled bytecode from different, more efficient languages like C and the like.

well, I guess it was just hopeful thinking on my part. LSL is one of the most woefully inadequate languages I've ever used. And that's comparing to BASIC too...

But it doesn't seem so bad: if Mono is what we all think it is, the potential exists to develop any language and compiler we like, as long as it produces CIL (or whatever bytecode is popular by the time Mono-vapor condenses).

The thing is, the inadequacies of LSL may be painful, but they don't really limit the functional possibilities in the way we're limited by the functionalities exposed at the VM. I'd gladly trade away #includes in perpetuity if today we could get script access to UI widgets with text entry, say, or set/get on all Group info, or...

Yes, if they would simply diversify the functionality of LSL it wouldn't be bad. At least, it should support the nominal statements of the C language. I'd sacrifice a Linden to get a switch statement...