The underlying feature arrived a while ago, but we've just made it discoverable:
(Notice that the last one has no right arrowhead; three is the limit.) The function input to MAP is given three inputs: the individual item, that item's position in the list, and the entire list. It may not be obvious from the pictures, but all I did between stages was to click the right arrowhead; these names are automatically provided.
So, you want every other item of a list?
You want a (toplevel) copy of a list?
This illustrates a subtle change: Normally, if you drag a variable into a Reporter input slot, the ring disappears, because 99% of the time, what you mean is that the variable's value is the function you want to use, not that you want to use the niladic function that returns the variable's value. The new thing is that if the variable you drag in is one of the ring's own formal parameters, then the ring doesn't disappear. So this says to call the identity function on each item of the list.
But that particular use case is common enough that we interpret an empty ring as the identity function:
This seemed like the right thing because leaving an input slot empty means to substitute the input into that slot, and you can think of the empty ring as one big empty slot, so it's fairly mnemonic, And the previous behavior (reporting an empty ring) was entirely useless.
Note that the value/index/list thing does not apply in COMBINE, which requires a two-input function. Nor does it apply in rings that aren't in HOFs.
Actually, I just dragged the ring out of the MAP, added the extra parameters, then dragged the ring back in. What do they report? I found out that it's just zeroes.
You mean for variadic inputs like LIST and JOIN? Limits, yes, definitely on my list, although Jens keeps putting me off. Names: I'm not sure what that would mean, since the caller doesn't see the input name.
I mean the MAP reporter has a limit of 3 parameters and the default names of value, index, and list; would I some time, for example, be able limit the number of parameters of the rings in my new Pinky Promise reporter to 2 and assign default names to fulfill and reject?
So, your custom block is declared to have a Reporter-type input, and you'd like to control what the ring looks like? Yeah, I guess that would be good. You're setting me up for a give-them-an-inch-and-they-take-a-mile rant from Jens (one of my jobs in our partnership is that when he feels like ranting at a user he rants at me instead) but I agree that that would be a cool feature. It's definitely not happening any time soon, and maybe never. (Among other problems, I'm shuddering at the thought of how you would specify these details, given that there's no visible ring in the Block Editor...)
I've thought that, too, but when I really think hard about it, I'm not sure how it could work. You would specify an input name FOO, click the upvar radio button and the variadic radio button (so we'd have to turn them into checkboxes instead of radio buttons), and then in the prototype in the Block Editor you'd have an orange button saying (FOO ↑ ...) and in the actual block in the palette it'd look like (FOO1) ◄► and if you clicked the right arrowhead you'd get a (FOO2) button. But how would the code in the Block Editor actually use the numbered variables? It doesn't have a variable FOO1 or FOO2; it just has one FOO. I suppose that could represent a list of ringed variable blocks, but... This is sounding really complicated and not so usable.
I love this new behavior of the empty ring. Because now you have by default what in the project below "by my inner 5-years old kid" is called a "transparent GLASSES" function.
Right. Also, if you give the ring explicit formal parameters, there is no substitution of inputs into empty slots -- you're supposed to use the parameters in the body! One use of this feature is to avoid substitution into an empty slot that you really want to stay empty.
Thinking about it. There is still a need for the multi-list MAP, and I can't (at least so far...) choose explicit formal parameters for a ring in a custom block. Possibly I'll end up rewriting that block using Javascript, which I should do anyway for speed reasons.
Here are my two cents worth thoughts. I wonder what is your opinion about them. So, my opinion is it would be better if:
their color was not orange because it makes a user think they can be treated by a user as "ordinary" variables when in fact they are treated as such only by (the internals of) the block, and not by a user
because to a user the parameters behave as operators they could be in green color,
a user shouldn't be given a choice to either name those parameters nor rename them.
EDIT:
It still doesn't work. What have I done wrong this time? ;-(
Umm. They are variables. There's nothing that stops the user from changing the value of one of them. (Of course the scope of that change is just the user's script. But it could still be useful if the script later uses the value of the variable. Weird, but maybe useful.)
And I'm not big on not letting people do things!
The problem with your MAP block is that when you give a ring explicit formal parameters (input names), we no longer do substitution of inputs into empty slots. So you should drag a VALUE block into the ELSE input slot.
I see, it was this "weirdness of their use" that made me feel that they shouldn't be (used by a user as) "ordinary" variables.
You could still allow both (as you are not big on not letting people do things ) because it would not break anything if both the empty slots and/or first formal parameter were substituted by the list's values.
EDIT:
I corrected it, still...
EDIT 2:
I just realized it is almost 2 AM where you live and you'll probably answer tomorrow. Good night.
I can still do that.
) because it would not break anything if both the empty slots and/or first formal parameter were substituted by the list's values.
