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?
The reason converting to block stack is so hard is that
Well there’s really nothing that can do it
The join block only joins blocks onto one line
Anything you attempt to do with turning the list into a shorter version just turns the blocks into xml
The best bet is if the devs make it so that the “set definition of block to” block can accept list inputs
Then you could do
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.
This is what we want to happen (excusing the “C”)
This is purely ment to separate stack blocks not their inputs
And while I do understand that I feel like there should at leas the a “stack” option in the split block that splits them based on their order in the stack
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.
I do agree with this tbh
I didn’t realize that a lot of these take away the fun of programming, if everything you need is already there then there’s no point in coding it!
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
If the window doesn't pop up automatically you can click on your profile photo on the top right of your screen, click on the "Profile" button, and click on "Drafts".
