The script variables block has a variadic upvar input. I would quite like it if custom blocks could have that.
Hi @donotforgetmycode_sn,
but you already have this feature.
and you have some example on libraries. For example, list utilities library have
with two upvars.
Joan
No, I mean the ability to control how many upvars there are by clicking on arrows. Like the Script Variables block. Basically, a combination of "Multiple inputs (value is a list of inputs)" and "Upvar - make internal variable visible to caller".
Ack, you also asked this in another thread, and I replied:
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.
What if FOO held a list of values, and those values are automatically transferred to the variables?
That would seem to me to be the best way to do it, but it would require a bit more effort to implement.
It's not a question of effort. It's a question of not making sense, at least to me. Upvars are made the same way inputs are made, but they're not inputs; they're more like outputs. They are given values by the procedure itself. So are you saying that the procedure says something like SET FOO TO (LIST A B C) and what that really means is SET FOO1 TO A; SET FOO2 TO B; SET FOO3 TO C? That's a little tricky, because the procedure doesn't know how many times the user is going to click the rightarrow, so it doesn't know how big to make the list.
It's all just so much easier to think about if you have one upvar and the procedure can assign a list to it of whatever length it chooses.
That's a fair way to view it, but for the list length specifically, FOO would already be set to a list with the same number of items as there are upvars (FOO1, FOO2, FOO3, etc.).
As an example of a (semi?) practical use case, you could create a multi-dimensional "for" loop that loops through lists with as many dimensions as you want, based on how many upvars you chose for the index variables.
Okay, I get it, yes, that's a good example use case. I'll discuss it with Jens.
How would input list work? The script variables input it actually a modified %mult%s input. It returns a list of names for the script variables block to initialize. How would you recurse on a list of upvars? Maybe you could place a block on it, that block being used for length, and have one upvar appear?