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.
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]."
Thank you for opening and not forgetting my code @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.
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!
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. :~)
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):
Second, indexed N-grams:
Third, using KEEP block to list the occurrences of a particular N-gram:
