Enhanced MAP, KEEP, FIND FIRST

[bh]

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.

[snapenilk]

I can still do that.

[bh]

Yes, you can construct a ring outside of the MAP and then drag it in, and we assume you know what you're doing. :~)

[snapenilk]

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.

[snapenilk]

Will ring parameter quantity limits and default ring parameter names be available for custom blocks some time?

[bh]

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.

[snapenilk]

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?

[donotforgetmycode_sn]

Also I would like variadic upvars, like the script variables block.

[bh]

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

[bh]

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.

[kinestheticlearning]

@bh

SNIP SNIP we interpret an empty ring as the identity function:

...the empty ring as one big empty slot.

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.

Or am I wrong?

[kinestheticlearning]

@bh

So, you want every other item of a list?

I tried to do the following, but it doesn't work as intended and I wonder why not.

[snapenilk]

The first parameter, no matter what the name is, is the value. The second parameter, no matter what the name is, is the index.

[legoman3.14]

Since you added the new parameters, are you going to remove the map and keep with index blocks from the list utilities library?

[bh]

@snapenilk

The first parameter, no matter what the name is, is the value. The second parameter, no matter what the name is, is the index.

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.

[bh]

@legoman3.14

Since you added the new parameters, are you going to remove the map and keep with index blocks from the list utilities library?

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.

[kinestheticlearning]

@snapenilk

The first parameter, no matter what the name is, is the value. The second parameter, no matter what the name is, is the index.

@bh

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.

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? ;-(

[bh]

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.

[kinestheticlearning]

@bh

Umm. They are variables (...SKIP SKIP...) weird, but maybe useful.

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.

@bh

... when you give a ring explicit formal parameters (input names), we no longer do substitution of inputs into empty slots.

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.

[donotforgetmycode_sn]

It works for me.