Right now, the plugin is ready made, I'm just working on a new snapblocks update that improves a lot of stuff, and adds some new snap 10 stuff.
You can find the discourse plugin source code here.
If there is a system on the forum to auto update plugins, then it could be installed right now, and then update when I release the update I'm working on.
Umm, I'm going to take that as a "no." I'm not the one who maintains the forum, and I'd rather not be in the middle of a chain. So please say when. :~) Thanks!
back to the topic. if break; doesnt work, we can make a contine; block, right?
What would a continue block even do?
End this iteration of a loop and start the next iteration.
if you are working on snap v11, maybe add these:
stop [this loop v] stop [this iteration v] stop the [next v] (2) [loops v] :: control cap stop the [main v] (2) [loops v] :: control cap stop the [next v] (2) [iterations v] :: control cap stop the [main v] (2) [iterations v] :: control cap
My only concern about that is, would they work for custom loop blocks? If so, how? And if not, won't that confuse users who don't know or care which loop blocks are primitive?
Yes. They can read a custom blocks definition and detect a loop block.
the 'stop the [ v] () [ v]' supports hyperblocks, so 'stop the [main] (list [1][3]) [iterations]' will stop the first and third iterations of a loop
Now you're pushing it. Be happy if you get what you asked for originally!
LOL, not a chance, tho.
Duh, I don't know why that slipped my mind, even though I've used that many times in text languages. I guess I just think about snap a lot differently than text languages.
What about just STOP [THIS LOOP] and STOP [THIS ITERATION]? I.e. C-language-family BREAK and CONTINUE respectively. Users can make those capabilities themselves with CATCH and THROW, but they're pretty common use cases and arguably we should have them primitively.
nah, if you need to use break in your loop you're using the wrong loop. Learn to program functionally and multi-dimensionally, and free your mind from loops 
Oh I completely agree. These wouldn't be for me to use! But there are lots of ways (albeit often inherited from Scratch) in which we provide tools for users who haven't seen the light yet. ;~)
I wouldn't have thought so, Brian 
The problem with adding those, is that how do they function in custom blocks?
I have thought about this for a while, and come up with how stop [this iteration] could work.
My initial idea was ti just make the script in the c-slot that stop [this iteration] was in, stop, but that raises an issue with not being able to stick it in an if block. One way to get around the stop [this iteration] stop the script in the loop slot that it's in, which will allow you to stick it in an if block.
I don't see any way to have a stop [this loop], because, what counts as a loop? How does it tell custom blocks to break out of the loop? Should the custom block creator have to take that into account, or will it be automatic?
The main reason I'm thinking about custom blocks, is because snap primitives are implemented in snap. Plus, languages that have continue and break usually don't allow you to create functions that have code blocks, like the built in loops, so these can't just be translated to snap without thinking about custom blocks.
Luckily we have this
so the user can tell us which custom blocks count as loops! :~)
I think the most straightforward way to implement this would be to "compile" those options, just before running, into CATCH/THROW pairs. The STOP block itself would become a THROW, i.e., a RUN; but we'd put a matching CATCH around either the C-slot input script (STOP THIS ITERATION) or around the loop block itself (STOP THIS LOOP). Since we wouldn't show these additions to users, we could just use gensyms as the tags.
And of course it'd find the closest enclosing loop; if you want to exit from one further out, you use CATCH and THROW explicitly.
Since libraries can overload primitives, I imagine that if I were less lazy I could implement this in Snap! using metaprogramming to find the loop. A project for someone...
That's what I was talking abouy here.
(sorry, I wasn't being very clear)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.