Execution contexts API does not match the design doc

[vitvakatu]

Hi, today I finally checked how execution context switch buttons are working in the most recent IDE, and I found out they does not.

After investigating, I noticed that with_enabled_context and with_disabled_context have unexpected signatures.
See design doc: https://github.com/enso-org/design/blob/main/epics/basic-libraries/write-action-control/design.md#control-of-single-nodes

Runtime.with_enabled_context:
Context -> Runtime.ExecutionEnvironmentName -> Function -> Any
Runtime.with_enabled_context context environment ~action =
## Implementation out of scope for design.

Actual implementation:

with_enabled_context : Context -> Function -> Text -> Any
with_enabled_context context ~action environment=Runtime.current_execution_environment = with_enabled_context_builtin context action environment

Notice that the action and environment arguments are swapped. The IDE emits the code that does not use named arguments syntax and expects the order of arguments as in the design doc.

Do we have some specific reason for such an order of arguments? Can we change it to match the design doc?

@hubertp @JaroslavTulach @jdunkerley

[jdunkerley]

We can flip them round the other way.
We have a default for the environment so normally put those last but doesn't need to be I don;t think,

@hubertp can you flip this order please?

[hubertp]

In general, default arguments should be last. I would argue the design doc is wrong (it also doesn't have the default, which in 99% of the cases the user shouldn't touch).
But I will check if changing the order makes a huge difference.

[vitvakatu]

But I will check if changing the order makes a huge difference.

Well, it is a difference between a working feature and a not working one.

Just so you know, I'm ok with changing the signature in the IDE, but let's talk about it and confirm this change with the authors of the design doc, @jdunkerley, and @wdanilo. I'm not convinced the default is what the user wants in 99% of cases, as you state.

[hubertp]

#6357 I believe this is much more awkward to use but 🤷

[hubertp]

Done