What's problem you are encountering?
Setting a VAR to "blank" fails in the custom block, but works outside of it.
What have you tried that didn't work?
Reset PC, browser, SNAP.
Post a project example, link, or screenshot:
I take the first 5 rows of a sprite pixels for size reasons, and store them in a var.
In a custom block that loops through the pixel table, I set some vars to some values. None of it is of any significance.
What happens is, within the custom code, the set scanData to "" code picks up pixel data values from another var. It never clears the scanData var.
However, if I swap the set var block with this one it works OK.
I inserted some waits so one can observe the changes of the scanData var. At no point, other than the initial clearing outside of the custom code, does it get cleared.
Just to be sure, I have already reset my PC, cleared the browser caches, restarted SNAP and Chrome, and reloaded and ran the program many many times with the same result.
In the TEST block, at least, your set-to-empty block is inside a FOR EACH, and so is subject to substitution of list items.
Luckily you're using the List library version with the # variable. So you can put your code in a ring and give it an explicit formal parameter to prevent substitution:
Come on, @bh, that's intentional, and it was you who insisted on it. If it were for me I wouldn't support implicit empty-slot parameters inside the "for each" primitive at all, they're not needed because we already have an upvar for that. But you wouldn't have it, remember? You can't have both, empty slots as empty slots AND as implicit parameters.
I do agree with jens here. Having empty slots as implicit parameters makes sense on the HOF blocks, as there are no visible upvars, you have to click the arrow to get an option. Forcing you to use upvars in that case would make you have to click the arrow to get them every time you use them. However in the , the upvar is already visible, ready to use, so it makes sense that if you want to use the current item, you drag the upvar where you need it. In my opinion, having implicit parameters in the list block is the same as having behave the same as , which it does not.
Just my opinion, though.
Yes, I know it was I who insisted on empty slot substitution, as in the HOFs. I see FOR EACH ITEM as being in the same family, and they all inherit that behavior from CALL and RUN.
The part that I think is a bug is that primitive C-shaped blocks don't offer the same feature as custom ones, wherein you can put a ringed script in the slot and it turns into an inline Command input. That would allow both using a formal parameter to preempt substitution and also the value/index/list feature. I've been wanting both of those things while working on the APL library, actually; mainly the latter.
While we're on the subject, it's just occurred to me that a great use of the hidden relabel feature would be to have multi-list MAP and FOR EACH as relabel options for the regular ones. That would help speed things up!
You're totally entitled to opinions! But my immediate disagreement with Jens is about what question we're discussing, never mind what the answer is. :~)
Yes in principle, but at this time the relabel list for primitives is entirely separate from the relabel list for custom blocks. I think we all agree that that's an undesirable limitation and we should fix it When Things Slow Down™.
But actually given how the design has changed since I first made these higher order procedures in Logo, I'm now leaning toward
Might there be a chance that Snap! would cope with it being a hidden primitive behind relabel and still be in the library?
As long as it didn't get upset/confused when the library is loaded it could be quick win-win?
New syntax for block would be great but can see that it would be a lot of work - maybe just add it to the library and slowly deprecate the old version over a period?
[edit]
Had a bit more of a think about this and realised there's a bit of inconsistency between using item or value - even within the same blocks such as keep and find first
The value/index/list feature is kind of hidden in the HOFs so as not to overwhelm the beginner. And also to encourage people to build their code so as not to need the extra information. I think the same should apply to FOR EACH.
Question for everyone: Does anyone besides me use the feature of substituting values into empty input slots of FOR EACH scripts on purpose?
You mean, not in MAP either? It seems that most people like it in the HOFs but dislike it in FOR EACH. I've never really understood that position, but I seem to be a minority of one, which is why I asked who else uses it.
In my experience teaching text languages pre-Snap!, one of the common stumbling blocks for beginners is the difference between formal parameters and actual arguments. I was forever seeing students build special cases into their procedures instead of using the argument value, or putting the actual argument expression they intended to use when calling the procedure in the prototype, where a formal parameter belongs. It seems so much easier, to me, to say meaning "add three to whatever."
I dunno, every decade or so, someone invents a programming language in which they use "it" as a pseudo-variable meaning "the last result" and I always laugh at them, but maybe this is my version of the same thing. But, as in many other cases, I think the visual language changes what's understandable or not understandable. There's something really intuitive and self-explanatory, I feel, about that empty slot. It jumps out at me. That's why I keep wanting a monadic − block; just seems to be crying out for something to go in that empty slot. (And is even worse; you'd never use a text language that made you say that.)
As a seasoned practioner, I like the fact that I don't have to drag the upvar into the empty slot. Its a great shortcut.
But I repeat my description of it as being auto-magical - it is not at all obvious or makes much sense to a Scratcher.
In Scratch, the empty slot is a default value of 0 or ""
Changing to the concept of it gets auto-filled is a BIG mental step
That's why I'm suggesting the compromise - with very little hope of acceptance as I realise as it is probably far, far too late in the day.
And even if you said - fair enough - lets change - it would involve a LOT of images in the BJC course and manual to change the map type block references
But I'm glad of opportunity to discuss the issue
And I feel changing the for each block is far less of a big job/visual change, especially if done over a period