# Send to REPL and multi-module projects **URL:** \ **Category:** Questions & Answers\ **Tags:** question, emacs\ **Created:** [March 16, 2026, 5:20am UTC](https://racket.discourse.group/t/send-to-repl-and-multi-module-projects/4146 "2026-03-16T05:20:36Z")\ **Posts on this page:** 14\ **Page:** 2
**Author:** ![EmEf](https://avatars.discourse-cdn.com/v4/letter/e/53a042/32.png) [@EmEf](https://racket.discourse.group/u/EmEf)\ **Post date:** [March 18, 2026, 1:18am UTC](https://racket.discourse.group/t/send-to-repl-and-multi-module-projects/4146/21 "2026-03-18T01:18:02Z")
My post was a long way of saying "I love it, please implement it." ---
**Author:** ![alexsh](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/alexsh/32/2598_2.png) [@alexsh](https://racket.discourse.group/u/alexsh)\ **Post date:** [March 18, 2026, 5:49am UTC](https://racket.discourse.group/t/send-to-repl-and-multi-module-projects/4146/22 "2026-03-18T05:49:34Z")
> [@greghendershott](#): > > Well dang. Clearly we need [Lorites](https://anathem.fandom.com/wiki/Lorite) in real life. Not just in [_Anathem_](https://en.wikipedia.org/wiki/Anathem). That's a funny and unexpected twist that reminds me to stop ignoring the exact same book that I only went half-through by now... 😃 ---
**Author:** ![alexsh](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/alexsh/32/2598_2.png) [@alexsh](https://racket.discourse.group/u/alexsh)\ **Post date:** [March 18, 2026, 5:52am UTC](https://racket.discourse.group/t/send-to-repl-and-multi-module-projects/4146/23 "2026-03-18T05:52:46Z")
> [@EmEf](#): > > (Of course this defeats the purpose of "work through examples before you design a function" but hey, there's good behavior and human behavior.) I have pretty much given up on instilling this attitude in other people, but I am still following it myself, so no such convenience for me — I still write my tests before implementation, that is when I am writing _any_ tests. 😅 ---
**Author:** ![alexsh](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/alexsh/32/2598_2.png) [@alexsh](https://racket.discourse.group/u/alexsh)\ **Post date:** [March 18, 2026, 6:09am UTC](https://racket.discourse.group/t/send-to-repl-and-multi-module-projects/4146/24 "2026-03-18T06:09:11Z")
> [@greghendershott](#): > > IIUC @alexsh uses `racket/gui` classes. In fact I am using SDL, and I am doing a kind of React-inspired UI toolkit myself. Mind, this is all still in Python, so I am trying to achieve separation of state and behavior by applying discipline pretty much. In Clojure with its Persistent (meaning Immutable) data structures that would be the default. > 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's also a possible way to do it I guess, but I haven't tried that. I think setting up all the required inputs is not that much in the way even. It may just look odd hanging on the empty screen as opposed to how it will work when you actually run the game. Need to give it a try and see — thanks for the suggestion! Now that I mentioned Clojure once again: is there facility in Racket that has the same effect as [`defonce`](https://clojuredocs.org/clojure.core/defonce)? That potentially would immediately solve the problem for me, as I would be able to re-evaluate all the code, while preserving whatever state I have accrued so far by interacting with the game. Structs and prefab — I am aware of already, but haven't read the manual up to classes yet. I do not know if I will be using them yet, though. 🙂 ---
**Author:** ![soegaard](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/soegaard/32/19_2.png) [@soegaard](https://racket.discourse.group/u/soegaard)\ **Post date:** [March 18, 2026, 10:24am UTC](https://racket.discourse.group/t/send-to-repl-and-multi-module-projects/4146/25 "2026-03-18T10:24:09Z")
I looked up `defonce` and see there are two aspects to it: - evaluating once - thread local values In Racket those concerns are usually split. To cache the result of an expensive computation we often use memoization. It's common to roll your own, but there are some libraries [1], [2] to use. To shadow "the root value" with a thread local value, use parameters. > **[4.13 Dynamic Binding: parameterize](https://docs.racket-lang.org/guide/parameterize.html)** Just be aware, that referencing a parameter is slower than referencing a normal variable. -- [1] [7.5 mischief/memoize: Memoized Functions](https://docs.racket-lang.org/mischief/memoize.html) [2] [define/memoize-zero](https://docs.racket-lang.org/memo/index.html#%28form._%28%28lib._memo%2Fmain..rkt%29._define%2Fmemoize-zero%29%29) ---
**Author:** ![soegaard](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/soegaard/32/19_2.png) [@soegaard](https://racket.discourse.group/u/soegaard)\ **Post date:** [March 18, 2026, 10:26am UTC](https://racket.discourse.group/t/send-to-repl-and-multi-module-projects/4146/26 "2026-03-18T10:26:01Z")
> [@alexsh](#): > > In Clojure with its Persistent (meaning Immutable) data structures that would be the default. Apropos Clojure - don't forget Racket now has immutable tree lists. > **[4.16 Treelists](https://docs.racket-lang.org/reference/treelist.html)** ---
**Author:** ![greghendershott](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/greghendershott/32/98_2.png) [@greghendershott](https://racket.discourse.group/u/greghendershott)\ **Post date:** [March 18, 2026, 2:18pm UTC](https://racket.discourse.group/t/send-to-repl-and-multi-module-projects/4146/27 "2026-03-18T14:18:02Z")
> [@alexsh](#): > > Now that I mentioned Clojure once again: is there facility in Racket that has the same effect as [`defonce`](https://clojuredocs.org/clojure.core/defonce)? That potentially would immediately solve the problem for me, as I would be able to re-evaluate all the code, while preserving whatever state I have accrued so far by interacting with the game. It wouldn't be hard to write a little `defonce` macro that behaves like all those examples _in a REPL_ on that Clojure doc page. i.e. If the var is already defined, it's a no-op. The question is, how do you "re-evaluate all the code" without blowing those away. Because the normal way in Racket is to evaluate/compile (e.g. `M-x racket-run`) the module, including all the definitions for code and data -- including any `defonce` ones. That process supplies no way to save/restore state AFAIK. 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. ---
**Author:** ![greghendershott](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/greghendershott/32/98_2.png) [@greghendershott](https://racket.discourse.group/u/greghendershott)\ **Post date:** [March 18, 2026, 3:30pm UTC](https://racket.discourse.group/t/send-to-repl-and-multi-module-projects/4146/28 "2026-03-18T15:30:14Z")
Although it's a long book, and not for everyone, I think the second half gets pretty fun, maybe someday if you have the time/mood for it. ---
**Author:** ![jryans](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jryans/32/31_2.png) [@jryans](https://racket.discourse.group/u/jryans)\ **Post date:** [March 18, 2026, 7:00pm UTC](https://racket.discourse.group/t/send-to-repl-and-multi-module-projects/4146/29 "2026-03-18T19:00:33Z")
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](https://racket.discourse.group/t/image-based-development-and-interactive-experience/3679/32) (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. ---
**Author:** ![greghendershott](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/greghendershott/32/98_2.png) [@greghendershott](https://racket.discourse.group/u/greghendershott)\ **Post date:** [March 18, 2026, 7:38pm UTC](https://racket.discourse.group/t/send-to-repl-and-multi-module-projects/4146/30 "2026-03-18T19:38:35Z")
No worries, I asked @alexsh to post here so that they wouldn't just get advice limited by own imagination or some Dunning-Kruger opinion of what's good-enough for game dev I don't do. 😄 Having said that, there's (1) advice for the reality of Racket, today. And also, (2) a someday/maybe discussion about how Racket could support a bigger subset of live-coding. p.s. I have some mileage with Clojure and especially with Emacs Lisp. I think I most appreciate the live _debugging_ scenario, which you mentioned -- poking a live system that's not working quite right. It's convenient to redefine a function with step debugging, redefine a function with a likely fix, and so on. Aside from debugging, for most of development? I find the live-coding style to be less of an advantage -- and sometimes downright confusing, e.g. accidentally using zombie definitions, mentally juggling what's changed or not, etc. In a system where the single source of truth is source files managed by git, I get uncomfortable wandering off that path too far, too long. But that's just me and my own experience and biases. Definitely not trying to argue against other people wanting other things. ---
**Author:** ![alexsh](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/alexsh/32/2598_2.png) [@alexsh](https://racket.discourse.group/u/alexsh)\ **Post date:** [March 18, 2026, 8:04pm UTC](https://racket.discourse.group/t/send-to-repl-and-multi-module-projects/4146/31 "2026-03-18T20:04:54Z")
> [@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". For the "big" project I'm starting I definitely have the plans to do some sort of event-sourcing to capture all relevant user's interactions with the game to be able to replay them later and reproduce and debug issues. Having to do that upfront feels like a major obstacle, however... Maybe I'll be better of biting the bullet and doing exactly that, but that does kill a bit of "fun" for me especially in the early stage. ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/racket/original/1X/4e853055ae989ed00f69341cd98bee95980776c4.png) [@system](https://racket.discourse.group/u/system)\ **Post date:** [March 18, 2026, 8:12pm UTC](https://racket.discourse.group/t/send-to-repl-and-multi-module-projects/4146/32 "2026-03-18T20:12:23Z")
---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/racket/original/1X/4e853055ae989ed00f69341cd98bee95980776c4.png) [@system](https://racket.discourse.group/u/system)\ **Post date:** [March 18, 2026, 8:56pm UTC](https://racket.discourse.group/t/send-to-repl-and-multi-module-projects/4146/33 "2026-03-18T20:56:32Z")
---
**Author:** ![benknoble](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/benknoble/32/16_2.png) [@benknoble](https://racket.discourse.group/u/benknoble)\ **Post date:** [March 20, 2026, 2:22am UTC](https://racket.discourse.group/t/send-to-repl-and-multi-module-projects/4146/34 "2026-03-20T02:22:01Z")
> Someone replied to a topic you are Watching. > > > ![](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jryans/45/31_2.png "jryans") | [jryans](https://racket.discourse.group/u/jryans) > > March 18 | > > > > - | - | > > > ![](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/greghendershott/48/98_2.png)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. Something roughly equivalent to the flow Greg describes was useful for bits of Frosthaven Manager. I could run individual components as standalone "applications," sometimes with some additional code/windows/etc. around to manipulate inputs. It was also great for making development maintainable. (I did have saved states that encompassed quite a bit, but certainly not "the entire internal state of the program"; still, when not fiddling with the save layout, I could also use saves to restore to specific bugs.) [Previous page](https://racket.discourse.group/t/send-to-repl-and-multi-module-projects/4146.md?page=1)