Are you expecting that "cont" will be "report ". And calling "cont" actually wiil be acting as returning the value of the reporter? So calling it twice will report twice , or restart the script ?!?!
This way continuation will be a "report" command.
But this stiil does not work.
Okay, one more time: There seems to be a bug in the implementation of call/cc. It's not a surprise that your rearrangement still doesn't work.
Sorry to have confused things with my request for the non-functional code. It was helpful. Although I still haven't quite got a handle on CPS but I'm reading up on it...
I tried a few other approaches, and then I boiled something down to a result that (at least) I didn't expect in the following code:
I didn't expect the +2 to occur, but I did expect +4 and +8 to occur. However, only +4 occurred. Why does telling hidden1 sprite to stop other scripts in its sprite, also stop scripts in this sprite (the one the block is in)? It may be a behavior everyone understands well, but I don't.
I think this is why some of the other answers I've been testing weren't working. I don't suppose this relates to the implementation of continuations, but rather, something I'm misunderstanding about the tell or launch blocks.
Can you help me understand it briefly? I know you're busy. Many thanks!
You should post a project link as well as a code picture with questions like this, because (in this case) I'd want to check whether RESPONSE was created as global or as sprite-local. If the latter, that would explain some of what happened.
I'm surprised you didn't see the +2, because it's done in the current sprite, not in HIDDEN1. But apparently you've found another bug (or maybe a misfeature; Jens is away for a week, so I won't know for sure which until he's back). TELLing another sprite to STOP [OTHER SCRIPTS IN SPRITE] stops scripts in this sprite, not the other sprite.
Anyway, it's not you who's misunderstanding; it's Snap!. :~/
My test project still does not work for you? Snap! Build Your Own Blocks
"tell" is synchronous and tell( "hidden", ()=>forever()) works ... forever.
Did you try using my method? If so, what happened? (just curious)
Yes but when the STOP stops that TELL's thread, the CHANGE (in the current sprite) should happen.
But it seems to work inside global block called this way 
This may help:
This is just in case your attempting to make your own script again.
No, it does not help, as things are even worse.
Script started this way belongs to the current sprite, not "Q".
Can be stopped only by
block of the current sprite, not Q.
This is talking about if he/she tries to make their own script (this is for future reference.)
Plus, this is about the launch block, this is not about telling another sprite to do something.
can be stopped
But yes, "launched" script should be controlled by global variables as they are not part of current script.
Then how does this example work:
It's a matter of closure, variables scope, and context sharing.
But the scripts differ. Look at the process/running script count
@bh, thanks for your reply... I'm happy to know I wasn't misunderstanding as much as I had thought. I've read the manual a few times now. 
I didn't know what I was in for when I agreed to help with my kid's school project. This language is really cool... and powerful! It's so much more powerful than Scratch, at least from when I last used it.
I am really sorry... still learning the etiquette. That makes complete sense though. You can't see variable scopes from the block pic. Yes, the "response" variable was a global. And here is a link to the test project. Please note that I added another variable change bit... so the output I'm getting now is 12. This is consistent with the unexpected behavior from the previous version. And yes, I guess I should have expected the +2 (and now, also the +8 I added), since they're not in hidden1.
I'm also not getting the +16 though (even after separating into a test project), which I definitely would expect. So this sprite's thread is stopping (rather than just those of hidden1), and I'm glad that seems counterintuitive to the development team. I thought I was losing it... It's kind of interesting that I'm getting the +8 but not the +16. That means that this sprite's thread is (mistakenly) stopping as to the original thread and 1st "launched" thread, but not the 2nd "launched" thread. Maybe that helps the troubleshooting? Just so I'm clear, if everything were behaving as you intended, response should end at 30, right? In other words, every one of these change commands should execute, correct?
Thanks again for the help. I will await your reply when your colleague returns. My kid says a great big thank you to all of you. We are so excited that you guys are helping us.
P.S. @dardoro and joecooldoo I'm definitely trying your solutions too. I tried them in the original project and couldn't quite get them to work like I wanted, but I will try them in isolation in this test project as well. As you say, maybe there's something else going on in the project other than the unexpected behavior we're discussing here. The family and I are going on a hike this morning, but I'll add it to the test project as soon as I get back. Thanks again for jumping in with this help!
Sounds like you have a great kid! :~) Is (s)he in a BJC class?
Yes, I agree, all the CHANGE blocks should run.
Scratch was designed to encourage the creativity of 8-year-olds. (They've since extended their target audience in both directions, but 8 to 12 was where they started the design.) Snap! was designed to teach teenagers computer science. So it's not that we're smarter than they are; we each had reasons for including or not including features.
First class continuations, in particular, are a sort of flag-planting; they're one of the signature features of Scheme, which is God's programming language, and Snap! is (among other things) an implementation of Scheme with a different user interface. We don't really expect many users to use continuations directly, although we use them to implement CATCH and THROW in the iteration-composition library.
I have an idea that would be helpful for this, but it might not get implemented (maybe I should put this in a new topic in the feature requests category). The stop block could accept a ringed procedure and every launched thread and run block that had it would be stopped.
set var [example] to (ringed procedure)
launch (example)
run (example)
say (stopped) //This runs if the run block finishes or is stopped like below
stop (example) //This stops the launched thread above and the run block (if each is still running)
I don't know what should happen in call blocks.
This doesn't make sense. It's just telling me how many processes are in that launched script.
that makes sense, the two launched scripts, and the script that ran the (processes) block.
I understand that, but, why are they showing me this?