So as even the developers have admitted minipulating multiple blocks inside of a stack is very bad
Minipulating individual blocks is actually pretty good! But there’s next to no proper way to manipulate rings that contain more than one line
Currently there’s only one tool that allows this, otherwise there would quite literally be zero way to manipulate block stacks inside rings
And that tool is “split by blocks”
Now what do you think this would report?
I just put the map ( list )) outside the join map, because the join map is for splitting the stack, but the list map is for putting them all into a list.
If you ever see me give a solution that obviously can be simplified, it's because I'm trying to demonstrate what is happening, and have it obvious that each part is doing something different. Yeah, I could simplify it, but then it would be harder to understand.
This also means that a find replace function can be created relatively easily
To detect c blocks we need to get the context it’s being found in
Or we could make specific ending blocks to add to c blocks, that would he preatty difficult
Maybe we could make c blocks a list of a list?
Your examples are a little unfair because the inputs to all the commands are constant numbers. For that situation, yes, the tree representation of the code is more complicated than necessary. But the representation has to work even when those inputs are complicated expressions:
(Yeah I know that example doesn't make much sense. I just threw some blocks together.)
But I agree that the representation can be simpler, by using a real abstract syntax tree, which would eliminate some special cases for variadic inputs. If I get my act together in time, I intend to write a metaprogramming library that will wrap some code around a SPLIT BY BLOCKS to report a tree structure that's bigger but simpler than the primitive one. Then people can write code based on those trees rather than on the ones the primitive reports.
The primitive has to be one representation that works for every case. We're not going to add a special case just for you. But maybe we (or you!) could write something for the library that does what you want.
If you have a variable list and then set that to a script variable, modifying the script variable modifies the original
This is done to reduce the amount of data being transported
It’s much more efficient to just reference the original list instead of having 2 huge lists
That untether block’s definition is
Because keep reports a new list
Here’s the block in action
See how it still reports 1 to 10, that’s because the “a” variable is referencing the new list created by the “keep” block
and never would have made “ammount of () in ()” or wow
Actually if this want an issue i probably would have never even learned how continuations work
And you would have never found out that the “catch and report” and “throw with input” blocks are missing the proper help message