Just a "styling" issue with your blocks - for want of a better word
When I was looking at the 1st block in your post, I got very confused about how it could possibly work as you seemed to be using a recursive function with no end case check
And then I got more confused as you seemed to have an identical named function (but with different type of parameters)
[ignore]And then there's a 3rd "identical" one
I think changing the labels would make things a lot clearer
You're right of course: the main function and the auxiliary function are identically named. I'm going to change the name of the second function (-> "HELPER ...").
The first image in my previous post (#21) is a "result pic" of the main function.The second image shows its implementation. The final image shows the implementation of the auxiliary (= second) function. There never was a third function. Or perhaps I've been missing a joke ( )?
Seriously: even though @cookieclickerer33 appears to consider her original question answered I'm convinced the function could be further developed so as to cover more cases. Follow the link in my previous post (#21) and you'll see what I mean. If you have any suggestions I'd be happy to receive those.
Not sure if it'll make sense out of the context of the project but here is a bit where I replace a command block with the result of a call to a reporter
Thanks for sharing. However, it looks quite complicated!
OK, here's one of my hobbyhorses In my limited experience ... code becomes more readable (and therefore: portable, maintainable etc.) if intermediate results are kept in variables with relevant names.
I also recommend changing the name of the “identity property “ reporter to just be “text ” or so that it’s more readable and easier to grab in the pallet
Do you mean the orange identity circle thingy in ... ?
That's not part of the function, it's just a test and demonstration script.
But it works with other (Snap! primitive) operators as well, provided there's no grey ring around it:
For me it depends on the number of intermediate results and the simplicity of the algorithm. A middle ground is the PIPE block.
As a teacher, rather than as a programmer, I want to be sure students don't think you have to put every intermediate result in a variable, so I think it's important to have some nested function call examples.
I agree to some extent - yet I feel that many (experienced) programmers - not excluding myself - tend to overuse composition, underestimating the self-documenting power of making intermediate results explicit.
I made another update to my my Find & Replace project for Snap ! code.
Now it can also handle block sequences. I found it especially challenging to replace a single block by a sequence of blocks, or vice versa.
This is an example of what it can do
This is the palette function, decomposing the input data and reassembling the output