Send to REPL and multi-module projects

[jryans]

Apologies in advance for my somewhat negative reply below... I would like to see state of the art live editing abilities in Racket some day. I am not yet entirely sure how to best achieve it in a Racket-y way, but I am interested in exploring possibilities if some have ideas...!

My takeaway from the last year's related thread (which @soegaard already linked above) was that the reloadable library is the closest match from existing Racket libraries, but it still forces you to divide your program into a "permanent" part and a "reloadable" part, with the state to preserve kept on the unchanging permanent side.

At the moment, I am not aware of a way to achieve a live editing workflow (where all state is magically preserved and function behaviour is edited in place) in Racket that matches the level available in Clojure, Common Lisp, etc.

@greghendershott

A more Rackety way would probably be a define/serialize macro responsible for restoring the state? How/when exactly it gets saved, idk? This pretty much leads back to the idea of "implement user save game state up-front, as a fundamental feature to also use during the dev process". So maybe this suggestion just reflects my lack of imagination.

This could work, but often a saved game does not precisely replicate all in-memory game state, but rather just enough to get you roughly back to where you were (saving most likely far less data as well). For a quick-turnaround development workflow, you'd want something more akin to "save all in-memory game state", but that might be a huge amount of data and also not the same as a user-created save state.

@greghendershott

I think I'd define functions to handle each of the five dialogs. That way, if I were developing the dialog that's normally called nested five deep: I could make my changes in the source file buffer, racket-run, and in the resulting REPL, I could call that function for the 5th dialog. Skip right to it.

That might work okay for simple bits of UI, but I am doubtful that it would scale towards game development in general. You may want to tweak something that depends on state you've only arrived at after a complex series of actions such as N character motions, wait M seconds, then do X, Y, Z. The code you wish to tweak might depend on a large bundle of global game state, all of which may have been modified by that series of actions. It could be challenging to identify a single function to extract that takes a small amount of state in the way you describe. Also, such function identification would have to be done in advance, before playing the game and encountering the problematic scenario. The key advantage of live editing workflows is that there is no setup needed in advance: you can simply edit any function in the program whenever you like and all state is preserved.