Yeah, that's a good way if the list is stored as a dynamic array (i.e., you created it with the imperative commands such as ADD). If it's a linked list, though, that way takes quadratic time and you should use the version in the list utilities library.
thanks for the information
Maybe get the list into a lifo stack(takes 2n time)
That's what the library version does.
I made a "reverse" function which that creates a linked list result.
This project measures and logs, to JS console, the performance of "reverse" for 100k elements: Snap! Build Your Own Blocks
It seems that the std library function is 5 times slower than the others for any kind of list.
Also, the OP function ("reverse dontforget") doesn't degrade for the linked list.
The source list is recreated every time to avoid the side effects of the list iterators.
Hmm. I guess I don't understand... Oh I see. The OP one converts linked to array just once, for the first item, and after that it's running in array mode. I think.
Sigh, maybe it's that Jens snuck in special code to slow down anything I write...
I'll dig into it more when I'm awake.
Your reverse block from the "Lists" library should do the right thing and always report a linked list. But it does get slow on a very long list. The "flash" reverse block from the "Frequency Distribution Analysis" library reports an arrayed list. But only that one.
I should have read the libraries carefully
Hmmm...
"reverse" from "List utilities" took 2000 [ms] for the 100k items list.
Version with compiled "map" or "combine" - 300-450 [ms].
"flash reverse" from "Freq... " library - 1-3 ms.
So the worst-case is 1000 times slower then JS.
Just for curiosity, for the same list (100k items) explicit conversion becomeLinked(), becomeArray() took ~20 and 1 [ms].