Ive been trying to make things such as switch / case blocks and text that appears only when a parameter is requested (like with inputs:) but have not found a viable way of doing these.
The Multi-branched conditional (switch) library implements that.
How about the with inputs: like with call and run? Also that's not exactly what I was hoping for. I was more looking for something like:
switch [value]
case [value]
code
case [value]
code
case [value]
code
Also, how would I properly format this?
Not yet. We definitely want this, and are thinking about how the user syntax should look, to make it discoverable and not confusing.
You could put a checkbox beside the multiple arguments option that says something like include "with inputs:" label
To be fair I believe that a custom UI just for labelling will solve SO many problems, essentially, a very simple UI that shows the entire label as it is and lets you click things to swap which one youre editing as well as link things like 'with inputs' or make two inputs share the same amount of parameters
It would also let you add options and stuff in a simpler way by either simulating the dropdown or giving you a menu to add them instead of instructions on how to write one up. Some tools I use allow you to group parameters together as one so you could make a switch statement like in my example by making the parameter a list or group of (predicate, code)
We don't want to special-case "with inputs." For example, the rightarrow in a gray ring opens a text "input names" followed by upvar-syntax formal parameters. And there are use cases for repeating the text for each new slot; think about variadic a+b+c+... or a AND b AND... Also cases for groups with more than one input slot, as in SWITCH {CASE (Boolean) (C-slot)}... ELSE (C-slot). The braces surround a repeating group.
So what we figure is a way to set up, for starters, an empty repeating group, then insert things in the group in the usual way, with + signs to click. And then some way to attach a "before first" group and an "after last" group (both optional) to the repeating group. What the group would look like is a raised platform, or maybe a lowered platform, followed by an ellipsis. I guess the way to create one might be a menu option in right-clicking a plus sign.
Really it's that beginning and ending optional group (why should it just be text? In fact if you think about variadic +, the beginning has to be a numeric slot, and the repeating part is "+ (number)") that need a good non-confusing notation.
At the same time we'll need something I've long wanted anyway: the ability to specify minimum, default, and maximum number of cases of a variadic input slot (or group, once those exist). The current only possibility is 0/1/∞ but there are clear use cases for 0/0/∞, 0/2/∞, and 0/0/1 also.
That's quite a good idea.
Thanks! I think so too. :~)
Yea, that sounds perfect. Then you can do exactly what I did in my code but without needing a special block to go inside of the switch statement (as it would be a list of lists).
Side note
Also, about the min and max stuff, the menu options should also follow in capabilities. Making variables 'multi-arg' disables the ability to give them any sort of special menu options (aside from multi-line or code) when clearly the options are based on which slot you click so the functionality would still work (i.e. piano, dial, dropdown, etc...). The empty dropdown menu option should be deleted as well and only placed there if the user adds a newline before adding new elements. Makes no sense for me to have "constant []" where inside the [] is just an empty string.
Grouping would allow this:
Layout:
table {$nl key: %key value: %value}...
source could be:
set [temp] to (list)
for (item) in (group)
replace (item (1) of (group)) of (temp) with (item (2) of (group))
report (temp)
Where group... would be an array
or
set [temp] to (list)
for (item) in (group)
replace ([key] of group (group)) of (temp) with ([value] of group (group))
report (temp)
Where group... would be a dictionary
Okay, yes, that's another interesting use case.
But, about the empty line in the menu, there's a reason for that: In our higher order functions we use empty slots to indicate that that's where an input item should be substituted, sort of an implicit formal parameter. So it has to be possible to leave any slot empty. It's not the intention that a block actually be run with the slot still empty! (Although it's clear in your example what it should do: display a help message!)