Does LSL do tail optimization in recursive algorithms?

The compiler in some languages will clear the stack if a function calls itself at the end of the algorithm thereby avoid stack overflows. Does anyone know if LSL does that? I'd be amazed if it does.

legacy LSL no, you could make stack overflows happen on a exact microsecond by calling functions within functions that went back to the original function (i actually got chewed out about that back in my noob days)

current LSL dunno, i havent been brave enough to try, becuase in most languages im currently using its still a major no no (go ask a lua scripter about dofiles calling dofiles, and they will probally refer you to a church)

upcoming mono, i doubt you could stack crap up like that, but its still bad mojo, you really should go back to your main (loop, event, state, whatever) to maintain total control even in the worst situations (oh like SL)

I don't think LSL currently does ANY optimization. Hopefully there will be at least a little bit of optimization when we compile to Mono. Really can't think of any reason not to (it's not even like we have a debugger to confuse; LOL).

Osgeld on that note I wonder if LSL prevents you from coding a recursive loop in (loops within loops within loops) which would be very bad, I haven't tried it and am not about to in case it actually is possible but it's an interesting and dangerous oversight if it's possible.

Edit: What I just said sounds similar to what you said above but I think I'm thinking of something slightly different although if/else looping if I remember my basic coding lessons would effect things differently than event looping.

Definitely no optimization. Unfortunately. I've written some things that use recursion, but given the memory ceiling, only under circumstances known to allow me to do so.

it doesnt matter what kind of loop it is

functions within functions

loops within loops

snahzberrys in snahzberrys

it will stack

I built an LSL heapsort implementation using recursion that works fine, if you can consider it fine for something designed to be made with real arrays or trees to be done with a linked-list style data type (meaning wildly inefficient). It stores any type and makes any desired comparison in order to sort, but was made to be visually represented in a linkset (thus limiting memory usage), so only 256 items can be sorted, leading to a low depth of recursion (7 or 8 deep).

So.. it can be done, sometimes.

Edit: Also, it takes MINUTES to sort less than 256 items, depending on the type and comparison. This is why it's good to know when you should actually use each data type and algorithm.

"Very bad?" The worst that is really going to happen is that you run out of memory and your script stops executing (you might hog a bit of script execution time until then as well, but at least it'll correct itself once you hit the stack-heap collision).

Why bother to make a sorting algorithm in LSL? The build in llListSort() will make a sort 100 or 1000 times faster I'm sure

Yes, it will, however it's fun to implement on your own. Also, the built-in sorter doesn't allow you to compare items in any way you please.

Thanks a lot for the input folks. It's what I was afraid of. Darn! It was such an elegant and simple algorithm. I'm going to go back to the drawing boards and try to redesign. If I get stuck, I may ask for further advice.

Just do the optimization yourself -- not a redesign but a standard conversion of recursion to iteration. In the case where the optimizer can do it, should be easy for you to do it too. The resulting code doesn't look as elegant, of course.

The LSL compiler does no optimization. It doesn't even optimize c++ to ++c when you don't use the output.

There has only ever been one instance where I've felt comfortable using recursion.