Set VAR to blank in custom code fails

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 image 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.

I also have made a video of it running on my PC:

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.

I hope someone can figure this out.

Thanks, TG

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:

The primitive FOR EACH doesn't let you do that, which is a bug imho @jens.

Well, you could always put a run block inside it.

Maybe an empty reporter will be less redundant...
untitled script pic (60)

Sorry dardoro, I did not quite understand what you meant.

Do you mean to make that block and then use it to set the scanData to it ?

Also, for the other answers:
I had written that tell block also worked.

However, I now understand why the problem was caused by the "for each item" usage. I will be careful of that in the future.


ScanErr script pic (1)

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 untitled script pic (12), 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 untitled script pic (12) list block is the same as having untitled script pic (13) behave the same as untitled script pic (14), 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. :~)

Can I further piggy back and request adding the library

untitled script pic (4)

as relabel option on


I've lost count of the number of times I've had to load the list Library just to get at that one block

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
untitled script pic

to work like the corresponding feature in MAP and friends (even though we'd have to redo a ton of pictures in BJC).

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?


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


maybe something like this


could square the circle?

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?

Could you give an example of what you mean?

I basically never use that ITEM upvar. Who needs it?

In the for each block, the item is exposed and explicit - I like explicit :slight_smile:

In map it isn't

Maybe a compromise is to expose the value in both forms but keep the index and list vars hidden


FTAOD I've never been a fan of empty slots getting auto-magically filled - shoot me now! :slight_smile:

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 untitled script pic 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; untitled script pic just seems to be crying out for something to go in that empty slot. (And untitled script pic 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. :slight_smile:

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 :frowning:

But I'm glad of opportunity to discuss the issue :slight_smile:

And I feel changing the for each block is far less of a big job/visual change, especially if done over a period

I seriously doubt...
bug_ implicit slot filling script pic
bug_ implicit slot filling script pic (1)
It quickly becomes counterintuitive and fails badly.

There was already a thread about this Strange implicit slot filling