One of the reasons for not substituting into empty slots when you use explicit parameters is that you might actually want an input to remain empty, and this is how you can do that.

The underlying central idea is that we should make easy things easy, like (( ) + 3), and also provide the standard thing (explicit parameters) for more advanced users to let them exercise fine control over what input goes where. For example, input substitution with multiple inputs works only if you use the inputs once each, in the same order in which you get them. So the equivalent of
can't be done by substitution into empty slots.

Can you open and click on the last block in this project, please, and maybe make a remix to correct whatever I made wrong. Thank you.

Do I understand correctly that you are saying that the block below, which works fine, using more than one empty slot, would not work if formal parameters were used instead? (Ignore a different "skin", saying "glasses" instead of "map" in this example.)

If you used explicit formal parameters, you would have to put the first (VALUE) parameter into all of those empty slots. Even if it were just one empty slot, it would not be filled if the ring had formal parameters.

This also explains why @donotforgetmycode_sn's code works and yours doesn't: he has "else v" and you have "else [empty]."

It's because your Map was a custom block, and you're supposed to be using the primitive Map block.

Thank you for opening and not forgetting my code :stuck_out_tongue: @donotforgetmycode_sn and finding out the reason why it didn't work. You're quite a detective! (I have completely forgotten that I've been using the non-primitive Map block in that project.)

That makes sense but my question is "easy" for whom? Clearly easy for the constructor of the program and anyone familiar with how Snap! treats empty slots but I found when showing Snap! programs to non-Snap! programmers that I was always having to explain the empty slots. So I've started using explicit parameters which I think improves readability in general (even if it slows down program construction). Especially if I give helpful names to those parameters.

I'm not suggesting any change to the language but maybe more sample programs, libraries, and documentation should use explicit parameters?

Do you mean non-programmers, or programmers accustomed to other languages? If the latter, it's not surprising that they recognize the notation they've learned, If it's non-programmers who find explicit parameters easier, then I'm more interested.

My own experience has been that people need to see an example, but that when they see the expression and the speech balloon with its value, they get it right away. That doesn't mean they can necessarily do complicated things, but they can do easy things, and the great thing about HOFs is that a wide range of practical problems are easy one-liners.

There are examples in the manual where something like nested MAPs make parameters useful. I guess we should experiment with things like ACRONYM, which can be done with empty slots, to see if parameters make it easier for kids to see how it works.

Or maybe this is a bad example?

I prefer (good) examples over theory.

I like the example and the Manual can have both of them, the empty-sloted one and the formal-parametrized one, explaining that both do the same.

I also like the acronym example. Personally I like the explicit version but it would be good to find out both what students like and which version they find easier to understand.

And I was referring to people familiar with other programming languages but new to Snap!

I think the Snap Manual should be updated because there should be no right arrow in the ring:

I also think you should add this feature to the For block:
scratchblocks (4)
(Sorry about how it looks like Scratch 2.0.)

Oh that's a great idea! I was trying to figure out how we would represent that since there's no (visible) gray ring in a C-shaped slot. I think @jens would be glad to do that next time he has soime time. :~)

Thank you.

Also, please remember to correct your spelling of "some".

:~P :~P

Changing it a bit, it can be shown how (indexed) N-grams (e.g. 2-grams in our case) are constructed using MAP block with explicit parameters, and how (indexed) occurrences of a particular 2-gram from a text (i.e. from a quote from the Manual itself, as shown below) can be listed using KEEP block below.

First, the "N-grams" script and its result (in a Table View):
N-grams script pic


Second, indexed N-grams:

indexed_N-grams script pic


Third, using KEEP block to list the occurrences of a particular N-gram:

keep items script pic