We don't need to list all overloadeded functions

As of now, we list all overloads of a function, e.g. string::Compose. When user selects a string::Compose for e.g. alphabet::BarSymbol instead of automaton::DFA, it works, because the selection of the overload is left to the ALT, so it is actually not needed. But we give user a visual warning that he chose a wrong overload (even if it works).

I'd like this to change.

• Let's list only one overload in the algorithm menu with a dropdown bar that shows all of them with appropriate docs (should the docs differ for every overload or should we unify the docs for all overloads?).
• Let's give the warning to the user only if he connects an edge from the box with a return value that cannot be used is absolutely not viable, i.e., it can't be used as an input for any of the overloads.
• However I am not sure how to deal with outputs of such overloaded box. Should we guess what the output is?

changed milestone to %BP

added C-webui P-high T-feature labels

So the ideal condition is that we can choose only one algorithm from the menu to canvas for all overloads of that algorithm? I don't really like the long lists with docs under so many dropdowns...maybe the algorithm could have button or something to show docs with parameters and return values in some dialog (it doesn't have to be interactive and some filtering options could be added there)? Maybe we could use some features from #57 (closed) or #56 (closed) as hint for user to choose the right output type on the basis of chosen parameter or use just some (i) button with available parameters or outputs.

Yes, having only one box for every algorithm would be nice. There are some caveats though, as described above.

I just think we should keep some basic docs for the algorithm (one or two sentences, perhaps take from the @briefdescription from class doxygen?) Then there might be additional docs for overloads (brief and detailed doxygen of the actual function)

I have two ideas, in both we’ll have just one box that we can put on canvas.

1. One box with number of parameters and return value with icon/button where will be listed allowed types of parameters and types of return values as popover (similar to i icon with version) - so that user can see allowed types next to the box. The best solution would be to show these allowed types when mouse is over the icon/button and on click show dialog with more detailed documentation - but now I’m not sure if this is possible with materialUI popovers.

• In popover we could list parameters “sorted” by return values, maybe these sets of allowed parameters for each return type could be used for “guessing” the return type.

Something like:

“1. parameter: Type1 / Type 2” “return: Type1”

“1. parameter: Type3 / Type 4” “return: Type2”

2. Second solution is not as user friendly as it should be, but safe with expecting return value. Showing just one box for one function but before putting it on canvas show confirmation dialog with possible parameters and return values. However it does not solve the warning when user select valid but different parameter or return type... https://v4.mui.com/components/dialogs/

I think that first solution could solve all related issues. And I think that the popover could be the same when showing hints on canvas.

mentioned in issue #76 (closed)

In combination with the first design, we could group the overloads by number of input parameters to be clear about input points on the box. Overloads could be represented as map< number of input params, overload[] > and for every key we could visualize one box - we could use some generic box only with number of parametrs (or maybe use name if the algorithm has named parameters) and have some element (button?) to display all available overloads. We could show some dialog or popover? I know we want to minimize the size of the boxes in the algorithm list, so we can’t list all of them in the box.

The best would be if we had some general documentation for the algorithm. I remember that we had some issues with this when we discussed Parse algorithm. Is something like this possible for overloads?

group the overloads by number of input parameters to be clear about input points on the box

I understand the needs to know the number of inputs but I'm not sure whether grouping by the number of inputs makes sense. What if there are two overloads with completely different types (and semantics) and third differing from the first one only in one param? Consider:

• Automaton, int
• Automaton, int, int
• vector, string, bool

But I admit I don't know how to do it better.

Is something like this possible for overloads?

I'm not sure, that's beyond my knowledge :-)

Yes I know that grouping by the number of parametrs doesn't make sense "semantically" (and it's not expected data model). But we can't merge the boxes with the different number of parameters (or we can but user would have to select it somehow, beacuse we can't guess the number of parameters, but that's not user friendly solution).

I'm not sure if it's possible to categorize overloads by semantics/types AND number of parameters. What would be the key of the map/the category? And the list of overloads could be still quite long.

Could you please enumerate which algorithms have overloads with different number of params? I suspect there is not much of them. Perhaps we can squash those with same number of params and list all for those which don't.

You can use curl to the API server and jq to parse the output

There's 9 algorithms:

"alphabet::generate::GenerateAlphabet"
"arbology::exact::ExactNonlinearTreePatternAutomaton"
"arbology::exact::ExactTreePatternAutomaton"
"automaton::generate::NumberOfSymbolsAutomaton"
"automaton::run::Result"
"cli::builtin::Dot"
"convert::LatexConverter"
"grammar::parsing::First"
"grammar::parsing::Follow"

Perhaps we can squash those with same number of params and list all for those which don't.

So the difference is that we'll list all of the overloads for the algorithms mentioned above? Should we sqaush algorithms with the same number of parameters just graphically? But the box should be able to show info (params, return value and docs) about all overloads that is represented by that box.

mentioned in issue #37 (closed)

mentioned in commit 10d01047

mentioned in commit a039d775

mentioned in commit 1a02d450

mentioned in commit 013f0a2d

mentioned in commit 320ac282

mentioned in commit d5bdc95d

mentioned in commit 0b60e907

mentioned in commit 1a141f09