Run code from a .sw file as part of a scenario's goal condition

[kostmo]

Is your feature request related to a problem? Please describe.

One may have goal evaluation code that is complicated and only feasible to write as a .sw file.
This code might be tested using real robots, so that the author can observe the code's behavior in real time.
When it comes time to convert that to a condition, would like to re-use the code from the same file.

Describe the solution you'd like

Definitions within that file should be brought into scope for "inline" use subsequently in the condition code.

Would like to be able to write the following condition code:

run "myscript.sw";

x <- function1FromMyScript;
if x {return false} {function2FromMyScript;}

Related observation

Organizing code into a "function library" .sw file for use across multiple scenarios does not seem possible today.

[xsebek]

We should implement import and solve this for REPL as well.

• Change run to import and typecheck it properly #495

Even unfinished import would be better than adding a hack for scenarios.

For example, even if import only accepted files with definitions and could only be written as the first command it would be enough to solve this issue and improve the overall experience by 100%.

Any hack for robots in scenarios will require the same work as "half-done import", so I would strongly advocate for doing that instead.

---

To be fair, there is a use case that we discussed previously with @byorgey for adding definitions to the base before starting the scenario to implement a DSL. (Not sure if it was another issue or on IRC.)

But with (even unfinished) import this could be much simpler, we could just let the base execute some code first without letting the player cancel.

---

Note that it is possible to reuse scripts across scenarios - all code needs to be part of the SW file and you can switch between it based on e.g. robot name or entity placed under the robot. See for example how the Move tutorial reuses code.

---

@kostmo please don't take this as a critique of the issue, it is a perfectly valid problem. But it is fundamentally caused by a longstanding imperfection of the run command. Your proposed solution would work, but it would duplicate the effort to solve the problem. My hope is that we can improve the run situation for the same cost and get greater benefits.

[kostmo]

Update regarding the specific issue called out in the title: I was actually able to make use of an external script in the goal condition, just not how I had initially envisioned. This works:

condition: |
    r <- robotnamed "sheep";
    as r {run "scenarios/Challenges/Ranching/gated-paddock/enclosure-checking.sw"};

Experimentally (see #835), it appears that the boolean result returned by the last invocation inside the script does get propagated outward to apply to the condition evaluation. But this is quite surprising, since the return type of the run command is supposed to be cmd unit, not cmd bool.

[xsebek]

But this is quite surprising, since the return type of the run command is supposed to be cmd unit, not cmd bool.

@kostmo if you read #495 that I linked, you will see it tries to solve this very issue:

• run prints value with bogus type #328

Since your feature request seems to align exactly with that proposal, shall we close this as a duplicate?

The root cause is the general problem of run that affects all places where we write swarm terms, including condition checking.

[byorgey]

I should add that relying on the fact that in this case run returns a boolean, even though its type suggests it should not, is perfectly ok for now. It's how run/import should and will behave in the future.

[kostmo]

there is a use case that we discussed previously with @byorgey for adding definitions to the base before starting the scenario to implement a DSL. (Not sure if it was another issue or on IRC.)

Filed #838 for this.