Definitions loaded via --run have their memory cells trashed

[byorgey]

Describe the bug
Any defs in a file loaded via the --run command-line argument (#312) will not work since their corresponding memory cell gets thrown away.

To Reproduce

1. In test.sw:

   def m = move end
   

2. Start the game via swarm --run test.sw.
3. Type m at the REPL.

This should generate an error about not having the right devices to move; instead, it generates fatal error: Reference to unknown memory cell 0.

Additional context

I think I already know why this is happening, but I am filing the issue just to be able to properly track and discuss it. This bug apparently has existed ever since #312 was merged, which I guess was insufficiently tested. It can ultimately be traced back to strangeness with typechecking run, and points toward the need to do something like #208 (comment) .

When the --run flag is used, we call initMachine to create a CESK machine that will execute the relevant run command. However, initMachine looks at the type and generated environment of the given term to decide what stack frames the CESK machine should start with. Since run(foo) has type cmd () but has an empty environment, initMachine starts the stack with only an FExec frame but no FLoadEnv frame. That means any definitions in the file being run will have the corresponding store thrown away. If the type of run properly took into account the definitions that will be generated when it is executed, this wouldn't be an issue.

[byorgey]

Hmm, actually, thinking about it more, I am not quite so sure the above is correct. FLoadEnv actually does not affect the store at all. And when the run command is executed, it replaces itself with a machine to execute the contents of the file --- which will indeed have an FLoadEnv frame at the end. So I feel like I am back to square one. I am not sure what is different between typing run(foo) at the REPL and starting with the flag --run foo.

[byorgey]

Trying to trace the exact code path that happens when we use --run; recording what I learn here.

• main in app/Main.hs calls appMain with the toRun argument being Just "test.sw".
• Swarm.App.appMain calls initAppState. The toRun argument flows nowhere else.
• Swarm.TUI.Model.initAppState
  • Sets skipMenu to True because isJust toRun
  • Hence calls scenarioToAppState with toRun and the initial game and UI state records
• Swarm.TUI.Model.scenarioToAppState calls scenarioToGameState with toRun to update the game state
• Swarm.Game.State.scenarioToGameState sets the machine of robot 0 to initMachine [tmQ| run($str:f) |] Ctx.empty emptyStore, where f is the text passed to the --run flag. All the robots are added to the active robot set.
  • initMachine calls initMachine'
  • initMachine', since the term run(...) has a cmd type, adds `
• Then we start the brick app, and the handleEvent function will start receiving Frame events. It will call handleMainEvent since uiPlaying is True, which calls runFrameUI, which calls runFrame, which calls runFrameTicks, which calls runGameTick, which calls gameTick.
• Swarm.Game.Step.gameTick, tickRobot, tickRobotRec, stepRobot, stepCESK

[byorgey]

I logged the exact sequence of CESK machine states that results when we run via the REPL vs via --run, and they are identical. So I realized it's something about the way the results are processed. I noticed that the REPL uses the replStatus to decide what to do, and realized that when entering something at the command line, the replStatus is set to REPLWorking, but this was not being done when running via --run. So I changed that and it seems to have fixed the issue. But I wish it were not all so fragile.