LSL status; mono usage; and using lsl as a target for a compiler

[Dom DaSilva]

Does anyone know the status of lsl? Is there an official grammar for lsl?

 

Are there other languages I could write in-world code in besides lsl? I had assumed that mono support would allow the use of other languages; but I seem to be mistaken.

 

Finally, I am aware of a few projects that are in the realm of language translation using lsl (a variant of Lisp and a Java to lsl project) but there are not many attempts to see if lsl can interpret or compile itself. Are there more such language translation projects in lsl, second life, or that are otherwise related to sl?

 

Thanks in advance for any help.

[Rolig Loon]

You may not use any language other than LSL for writing scripts in SL.  The "official" grammar is incorporated in the LSL wiki, which is maintained by those of us who write scripts here.  There is no grammar provided by Linden Lab.

[Qie Niangao]

---

otherwise related to sl?

---

Just in case: The "next generation" virtual world from Linden Lab, code-named "Project Sansar," will use a C# Mono compiler, instead of the LSL Mono compiler that was developed specifically for Second Life (for compatibility with the original, non-Mono compiler, which is still available).

You are correct that, back when SL's Mono implementation was very new, there was some effort towards a C# alternative to LSL. Such a thing might have removed some of the superficial annoyances of LSL, but it wouldn't have affected any of the real limitations of programming Second Life scripts. Unless there are much deeper changes than just a shift to C#, scripting in Sansar will have much the same limitations.

[Dom DaSilva]

Thank you for your input

[Dom DaSilva]

Hmm. Your description of lsl's mono implementation as being 'very new' is a bit worrisome to me; tells me how long I've been away from second life.

 

I last had been in SL since just before LSL was put into it's current mono implementation.

 

I would greatly appreciate having more reason to use C# beyond the usual 'get out of the vb.net 'ghetto'' attempts I have occasionally been making.

 

Thank you for the information; hopefully 'Project Sansar' will be that alternative to lsl that is needed.

[Kelly Linden]

---

Qie Niangao wrote:

Unless there are much deeper changes than just a shift to C#, scripting in Sansar will have much the same limitations.

---

Heya Qie, long time no chat. What specifically would you like to see addressed, in terms of deeper changes and limitations in SL and LSL?

[Qie Niangao]

---

Kelly Linden wrote:

---

Qie Niangao wrote:

Unless there are much deeper changes than just a shift to C#, scripting in Sansar will have much the same limitations.

---

Heya Qie, long time no chat. What specifically would you like to see addressed, in terms of deeper changes and limitations in SL and LSL?

---

Hi Kelly, good to hear from you.

I was referring to limitations inherent to any platform supporting user-generated scripts: the need to apportion resources among competing consumers by some quota system or another.

In the context of C# for SL, some scripters had unrealistic expectations of using whole cushy libraries; imagine the "learning opportunity" about how memory- and compute-intensive are our usual application programs if they were to be squeezed into 64K chunks and given only their fair shares of sim frame time!

In Sansar, though, there could be a somewhat different strategy for sharing resources, if I understand the business model correctly. That is, those who pay to deploy Sansar experiences just might have more flexibility in how they dedicate resources to one or another use. (Maybe.) If so, such deeper changes could materially enhance the programming environment in ways that SL and LSL couldn't reasonably achieve because in SL, the same quotas must apply uniformly to every script of every owner in every sim.

Something similar may extend beyond the computing resources used for generating the Sansar experience to flexibility about how scripts are allowed to affect users, including permissions, expected graphics capacity, viewer features -- even viewer-side scripting.

Finally, in an ideal world (for scripters), functionality would not be exposed to the viewer until it's also available to scripts. The idea of "bots" to perform rote functions should be obsolete; the risk of security or performance degradation should be handled the same whether triggered by script or viewer because ultimately they're the same threats. The resulting uniform API to the virtual world would enable fully scripted testing of all services at representative loads.

Hmm. I didn't really set out to write a manifesto. Sorry if I made you sorry to have asked.

[Kelly Linden]

---

Qie Niangao wrote:

---

Kelly Linden wrote:

---

Qie Niangao wrote:

Unless there are much deeper changes than just a shift to C#, scripting in Sansar will have much the same limitations.

---

Heya Qie, long time no chat. What specifically would you like to see addressed, in terms of deeper changes and limitations in SL and LSL?

---

Hi Kelly, good to hear from you.

I was referring to limitations inherent to any platform supporting user-generated scripts: the need to apportion resources among competing consumers by some quota system or another.

In the context of C# for SL, some scripters had unrealistic expectations of using whole cushy libraries; imagine the "learning opportunity" about how memory- and compute-intensive are our usual application programs if they were to be squeezed into 64K chunks and given only their fair shares of sim frame time!

In Sansar, though, there

could

be a

somewhat

different strategy for sharing resources, if I understand the business model correctly. That is, those who pay to deploy Sansar experiences just might have more flexibility in how they dedicate resources to one or another use. (Maybe.) If so, such deeper changes could materially enhance the programming environment in ways that SL and LSL couldn't reasonably achieve because in SL, the same quotas must apply uniformly to every script of every owner in every sim.

Something similar may extend beyond the computing resources used for generating the Sansar experience to flexibility about how scripts are allowed to affect users, including permissions, expected graphics capacity, viewer features -- even viewer-side scripting.

Finally, in an ideal world (for scripters), functionality would not be exposed to the viewer until it's also available to scripts. The idea of "bots" to perform rote functions should be obsolete; the risk of security or performance degradation should be handled the same whether triggered by script or viewer because ultimately they're the same threats. The resulting uniform API to the virtual world would enable fully scripted testing of all services at representative loads.

Hmm. I didn't really set out to write a manifesto. Sorry if I made you sorry to have asked.

---

I'm not sorry I asked at all. These thoughts closely align with my ideals. A "uniform API to the virtual world" is probably the toughest of them in practice, but it clearly has high value. More flexibility in resource management is also important, as well as better "permissions" models. Thanks for the reply.

 - Kelly