Can the NAME of a list be changed automatically to a new new LIST NAME by the script itself?

[dd Temin]

Can the NAME of a list be changed automatically to a new new LIST NAME by the script itself? 

if so can one of the scripting experts show an example here. Thanks so much.

[Rolig Loon]

No

[dd Temin]

@Miss Loon, Thank you for the fast response, have a great day. 

[Quistess Alpha]

Yes and no, you can always create a new list with the same content, but then you'd be changing the variable scope in most cases.

[Rolig Loon]

1 minute ago, Quistess Alpha said:

you can always create a new list with the same content,

True, but that's not renaming the existing list.  It's replacing it with a new list.  I think we've all found loads of places where it would be handy to let a script rename variables on the fly, which is what the OP is asking.  LSL doesn't give us that magical power, sadly.

[Quistess Alpha]

2 minutes ago, Rolig Loon said:

I think we've all found loads of places where it would be handy to let a script rename variables on the fly

I can't think of any way that would be useful. Any examples?

[Rolig Loon]

I can think of several.  For example, suppose my script is meant to keep track of data for each visitor to my area.  If I save data to KVP, I can create a new key for each person and use the person's name or UUID in the name of the key. I cannot do the same for lists in my LSL script itself, though. That is not a show stopper limitation,  but it would be much easier to tell which list is which if the identifying info was right in the name of the list. It would make some sorting and retrieval processes easier. 

This limitation doesn't keep me awake at night,  but  I  have wished for ways to let scripts name or rename variables on the fly many times over the years. 

[Quistess Alpha]

if you could rename variables, wouldn't you also need to be able to access differently named things? and make accessing something by the wrong name a run-time rather than compile time error? Pointers, are indeed something I'd get behind, but not having them has taught me how to be more clever with big combined lists and index variables.

As for your specific example, the easy way to do that is something like

list KVP_Data;

integer add_pair(key ID,list value)
{
  if(llListFindList(KVP_Data,(list)ID)==-1)
  {   KVP_Data+=[ID,llList2CSV(value)];
  	return 0; // unix style return values, 0 = no error, otherwise error.
  }else
  { // throw a runtime warning.
    return 1;
  }
}
integer replace_pair(key ID, list value)
{
  integer index = llListFindList(KVP_Data,(list)ID);
  if(index==-1)
  {  // throw a runtime warning
     return 1;
  }else
  {  KVP_Data=llListReplaceList(KVP_Data,[ID,llList2CSV(value)],index,index+1);
     return 0;
  }
}
list fetch_pair(key ID)
{  integer index = llListFindList(KVP_Data,(list)ID);
   if(index==-1)
   {  // throw runtime warning
      return [];
   }else
   {  return llCSV2List(llList2String(KVP_Data,index+1));
   }
}

Although, less-general solutions might be more efficient.

P.S. In things like this it's important to consider collisions between lookup names and data values. in the above example collisions should be avoided, because the keys have the key data-type and the values have string datatype.

[Mollymews]

a way to avoid collisions in list lookups is: http://wiki.secondlife.com/wiki/LlList2ListStrided

a generalised lookup example:

list fetch_record(string id, integer recordlen)
{
   recordlen++;
   integer index = llListFindList(llList2ListStrided(datalist, 0, -recordlen, recordlen), [id]) * recordlen + 1;
   if (index < 1)
      return [];
   else
      return llList2List(datalist, index, index + (recordlen - 2));
}

// usage
   list datalist = [some, global list structured as a fixed width table of records
                    where, the 1st field of each record is a unique key/id];


   // table width 2: key + value
   list data = fetch_record(somekey, 1);
   // data == [data1]

   // table width 3: key + (value,value)   
   list data = fetch_record(somekey, 2);
   // data == [data1, data2]

 

 

[Rolig Loon]

1 hour ago, Quistess Alpha said:

if you could rename variables, wouldn't you also need to be able to access differently named things? and make accessing something by the wrong name a run-time rather than compile time error? Pointers, are indeed something I'd get behind, but not having them has taught me how to be more clever with big combined lists and index variables.

I agree, both with the additional considerations you mention and the fact that there are often ways around many of LSL's limitations.  You asked, though, whether there are situations when it might be useful to be able to have a LSL script change the name of an existing variable.  The example I gave off the top of my head is not necessarily the best I would give if I were pressed to the wall, but it's an illustration of a task that is quite simple if we are dealing with naming KVP keys but rather difficult if we want to name internal lists in our scripts.  Yes, we can sometimes create workarounds to deal with them.  When you've been writing LSL scripts long enough, you've learned loads of workaround tricks.   I think you'd agree, though, that it would be nice if we didn't need those tricks, and there are some situations where we just don't have workarounds.  (Yes, pointers are another example of things we have learned to do without but still wish we had.)

[Quistess Alpha]

1 hour ago, Mollymews said:

http://wiki.secondlife.com/wiki/LlList2ListStrided

Yeah I had thought of that too, I didn't mention it because A) I didn't feel like trying to implement it, and B) creating a strided list temporarily uses at least half the memory of the parent list. If key-value collisions are likely/ really important to avoid, using two separate synced lists might be preferable. Every solution has benefits and tradeoffs.

37 minutes ago, Rolig Loon said:

I agree, both with the additional considerations you mention and the fact that there are often ways around many of LSL's limitations.  You asked, though, whether there are situations when it might be useful to be able to have a LSL script change the name of an existing variable.  The example I gave off the top of my head is not necessarily the best I would give if I were pressed to the wall, but it's an illustration of a task that is quite simple if we are dealing with naming KVP keys but rather difficult if we want to name internal lists in our scripts.  Yes, we can sometimes create workarounds to deal with them.  When you've been writing LSL scripts long enough, you've learned loads of workaround tricks.   I think you'd agree, though, that it would be nice if we didn't need those tricks, and there are some situations where we just don't have workarounds.  (Yes, pointers are another example of things we have learned to do without but still wish we had.)

I do indeed agree that it would be better if we didn't need to use workaround tricks for things, but on the specific issue of dynamic variable names, I have to say I don't see that in particular as a useful feature, the considerations that would have to be made to make it possible would make LSL harder for me to use, and I'm not familiar with any other language that lets you change the name of a variable (a quick DuckDuck turns up a few database languages which can do that, like R)

I am however familiar with being able to change which variable is being accessed, for example in bash:

let i=5
let j=6
let k=7
for x in {$i,$j,$k} ; echo $x

Although, I think that sort of thing would make more sense to do with pointers.

[Mollymews]

i think OP asked, as is possible to do this in a few other languages that run on Mono. PHP, Python, Javascript, Ruby and some others

is mostly a legacy thing tho, as quite a few high-level languages began as interpreted languages which lend themselves to dynamic programming. What is sometimes referred to as self-modifying code, which in the way back was often done in assembler / machine code on limited memory devices. So when interpreted languages become a thing back in the day, on these then memory-limited devices, the capability to self-modify was continued  

as an aside

i wouldn't mind the DYNAMIC variable declaration found in languages like VB and C# on Mono. Where the variable type is evaluated at runtime

example:
 

dynamic b = [1,2,3];
dynamic c;
dynamic a;

a = b;  // a is written to as type list
c = (string)a;  // c is written to as type string
c = b;  // c is now of type list

but then I also would like ByRef for user-defined function parameters, and struct variables as well. So that Rider Linden person still has lots of work to do to give me what I want 😸

ByRef particularly for list parameter passing would be a real blessing

example:
 

dosomethingwithlist(byref list d)
{
   ... do something with d
}

touch_start(integer num)
{
   list a = [1,2,3,4,5];

   dosomethingwithlist(a);
    
   a == [some,thing,done,with,list];
}

 

[Love Zhaoying]

Be careful, if you rename the list, you may never find it again!

[Profaitchikenz Haiku]

4 hours ago, Love Zhaoying said:

you may never find it again!

Have you looked behind the fridge?

[Nova Convair]

It is not a limitation of LSL that you can't rename variables and functions or whatever. LSL is not interpreted but compiled. Names do not exist in the compiled code - just pointers.

It might be possible to make a compiler-language that can do such things. That will lift the problems and debugging (did I mention that LSL has no debugger?) to a much higher level - will surely be alot of fun. 😁

[Love Zhaoying]

3 hours ago, Profaitchikenz Haiku said:

Have you looked behind the fridge?

Yes, weird radiator was behind it..

[Profaitchikenz Haiku]

12 hours ago, Nova Convair said:

It might be possible to make a compiler-language that can do such things.

Forth could do it.

[Profaitchikenz Haiku]

9 hours ago, Love Zhaoying said:

Yes, weird radiator was behind it..

I believe they're Transylvanian bagpipes

Edited August 24, 2021 by Profaitchikenz Haiku

[Nova Convair]

There is no need to rename variables, there are always other ways.

Since LSL has only lists and JSON strings for bigger data structures I can understand that people get all kind of wishes around that.
But you can do everything with lists - absolutely everything. Often it will be painful or slow or both though. No pain no gain! 😁

LSL was made for small inworld tasks and like everything that you give to a crowd it's already abused and overused.

So stop dreaming and instead just use what you have to solve your problem - it is possible. 😎

[Mollymews]

9 hours ago, Nova Convair said:

stop dreaming

nevah !11!!  😺

while am dreaming my 4th wish is for state scope variables and state scope user defined functions. Example:

state a
{
    integer myfirst = TRUE;

    initialiseOneTime()
    {
        myfirst = FALSE;
    }
   
    state_entry()
    {
       if (myfirst)
       {
          initialiseOneTime();
       }    
    }
}

[Qie Niangao]

58 minutes ago, Mollymews said:

while am dreaming my 4th wish is for state scope variables and state scope user defined functions. Example:

Interesting example, as it shows that your state scope variables are static. Until I read the example I assumed they'd reinitialize each time the state is entered, which changes their usage quite a bit. If static, they seem "syntactic sugar" for global memory, permitting the same variable names to be overloaded but otherwise behaving as uniquely named global variables. In contrast, if they reinitialize they'd be like locally scoped variables in functions or event handlers, and the memory could be re-used in other states.

But as long as we're dreaming, I occasionally long for static local variables in functions and event handlers, too.

[Profaitchikenz Haiku]

I dream of arrays.

[Mollymews]

2 hours ago, Qie Niangao said:

Interesting example, as it shows that your state scope variables are static. Until I read the example I assumed they'd reinitialize each time the state is entered, which changes their usage quite a bit. If static, they seem "syntactic sugar" for global memory, permitting the same variable names to be overloaded but otherwise behaving as uniquely named global variables. In contrast, if they reinitialize they'd be like locally scoped variables in functions or event handlers, and the memory could be re-used in other states.

But as long as we're dreaming, I occasionally long for static local variables in functions and event handlers, too.

i like your idea of local scope variables being non-static as well as static. Thinking about it more then:
 

state a
{
   integer a;   // lives for the duration of the state

   static integer b; // lives for the duration of the script
}

 

 

[Mollymews]

2 hours ago, Profaitchikenz Haiku said:

I dream of arrays.

i think it would be useful if we could address a list as we can in other languages. I think tho we might need dynamic variable type to help make it type safe. Example:

list a = [1,2,3,4];

dynamic v = a[0];

a[0] = v;

 

 

[Wulfie Reanimator]

20 hours ago, Mollymews said:

i think it would be useful if we could address a list as we can in other languages. I think tho we might need dynamic variable type to help make it type safe. Example:

list a = [1,2,3,4];

dynamic v = a[0];

a[0] = v;

 

Firestorm's LSL Preprocessor tries to give you this ability.

list items;

items[0] = 1;
items[1] = "second";

llOwnerSay(llList2CSV(items));

integer num = (integer)items[0];
string str = (string)items[1];

llOwnerSay(llList2CSV([num, str]));

 

Edited August 26, 2021 by Wulfie Reanimator