Preserve the input when changing a dropdown - how to crack it

[farmaazon]

The feature description here: #13281 - shortly, when user changes Widget Selection option from one method/constructor call to another, and both have the same parameter name, the parameter value should be preserved.

Here we have a problem with "dynamic" Widget Selection configuration (Single_Choice) with autoscoped constructors (like ..Equal, ..Not_Equal), because GUI has no means by itself to ensure what constructor exactly is called in that expression.

From our brainstorming, we got 4 ideas:

Just wait for expression update

Most "complete" solution, requiring work only on GUI side, but bad for the user, as they will see value restored (or removed, depending on our approach) only some time after changing selection.

Require Argument names in dynamic configuration

Singe_Choice options sometimes contains argument names with special config attached to them. We may add an option to just specify arg names without config, and make it required for arguments being preserved.

Requires some work on libraries' side. Also, I'm not sure if we want "don't preserve arguments" being a default behavior.

Additional engine's API for resolving expressions

We might ask the engine about some expression, what method pointer it calls at a given argument place. Still asynchronous, but we could call it once the widget loads, to have the information handy when the user actually clicks an option. I think it require substantial work on the engine side

Dynamic config with FQN and a flag to "autoscope it"

Instead of getting just ..Equal expression, the configuration could have fully qualified name, which is then turned to autoscoped version on the GUI side. Requires changes in libraries + not always autoscoped constructor will resolve back to the same FQN.

No solution seems ideal to me. Any comment or other idea will be welcome.

[JaroslavTulach]

Simple Atom Switch

Hello Adam. The example provided by James in #13281 shows a simple switch from one atom of a type to another atom of the same type. E.g. the picture

shows a switch from one Filter_Condition instance to another Filter_Condition instance. E.g. from Filter_Condition.Equals to Filter_Condition.Not_Equal.

• It is my understanding that Enso Studio already knows that ..Equals resolves to Filter_Condition.Equals.
• The Studio also knows all the atoms of type Filter_Condition as they are provided by @4e6's suggestion DB
• Thus the Studio may know that ..Not_Equal will resolve to Filter_Condition.Not_Equal
• and that both Equals and Not_Equal atoms have an argument to

Based on the above information I believe the Enso Studio can insert (..Not_Equals to=prev_value). Such a change can be done synchronously when the user switches the choice.

Know

"May know" or "may guess" - the exact conditions when it is safe to know and how much safe is safe may be subject of further discussion.

[farmaazon]

I assumed the premise "if ..A resolves to one type, then ..B resolves to the same type" is not true in general case: like when a method accepts type union for example (do type unions support autoscoping?). As a matter of fact, in my knowledge the autoscoped constructor may be resolved very deep in the function, and even depend on external state in some frantic cases.

But to cover basic scenarios this sounds like a good idea.

[JaroslavTulach]

not true in general case

Yes, that's correct. The whole idea of autoscoped constructors is to not know exactly and find out later. However the Filter_Condition usages are straighforward and follow very basic scenarios.

do type unions support autoscoping?

Yes, they do. The order is important in such a case. The first one that has the right constructor resolves the ..Xyz.

...cover basic scenarios this sounds like a good idea.
Enso Studio can insert (..Not_Equals to=prev_value) synchronously

• I'd try to keep the to=prev_value when it seems to make sense (as it does in the case of Filter_Condition)
• I'd schedule an execution and wait for its result
• If the evaluation errors (with some known error?)
• then I'd asynchronously rewrite again to just ..Not_Equals