A fast but more CPU-intense version of the [scratchblocks]for each ((item)::list) in (list){
}::list[/scratchblocks] block.
This block utilizes the MAP block and a reporter version of the RUN block to compute the scripts. It's faster than the FOR EACH (ITEM) IN (LIST) block but slower than the MAP block.
https://snap.berkeley.edu/snap/snap.html#present:Username=joecooldoo&ProjectName=Quick%20FOR%20EACH
For me warping the primitive for-each block is still slightly faster. Do you have an example where your version might work better?
not really, it's not my most practical block.
That's a clever idea, but officially you can't build FOR EACH out of MAP, because FOR EACH guarantees left-to-right order but MAP doesn't.
???
FOR EACH goes from the start of the list to the end
MAP will go in whatever order it wants to
based on my tests it doesnt do that
maybe something to do with adding, deleting, or replacing list elements while it's going, or some even rarer cases
maybe it'll just be different on later versions
Our MAP actually does use left-to-right order. It pretty much has to, for linked lists, and for dynamic arrays the ordfer doesn't really matter. But the definition of MAP doesn't say anything about order. When the hardware people reach the point where you have 1000 processors in your computer, then MAP will work in parallel, but FOR EACH will still go left to right.
This distinction matters because in the case of FOR EACH the action you perform for each sprite might change the state of the program so that the result for one sprite changes the behavior for the next sprite. Whereas MAP takes a function as input, in the mathematical sense of "function," namely that it has no side effects, so the order of computation shouldn't affect the results.