Originally asked here: Send to REPL and multi-module projects · Issue #766 · greghendershott/racket-mode · GitHub Hi! I am starting a project where I will have many module files, but it seems that "send to REPL" functions are not module-aware, or am I just missing some detail? Given the following two files: mod1.rkt: #lang racket/base (require "./mod2.rkt") (define t 1) and mod2.rkt: #lang racket/base (define t 2) I do racket-run while visiting mod1.rkt. Then I visit mod2.rkt and try to send the definition of t with racket-send-definition. It does succeed, but overrides the t from mod1. I need to be able to re-define in a module-aware manner (i.e. the way it works in CIDER for Clojure). Ultimately I'm aiming to develop a video game, and hot-reloading is critical for faster feedback loop, because it eliminates the need for re-starting the game and navigating to the place I was editing (restoring the internal state). The single-module workflow seems to satisfy my needs, but there is no way to fit the whole game in a single module/file. Re-running the module seems to discard the state, which is not what I need... Any pointers greatly appreciated! :slight_smile:

Thanks for posting here -- I think you'll get better advice and explanations! For example, I was going to reply something like: "If I were developing a game in Racket, I would start by figuring out how to persist game state -- which I'd eventually expose to players as a feature -- and that use from the start to develop, do unit tests, do perf tests, etc." But. You should probably listen to people who have actual game development experience, not me. :smile: p.s. Maybe relevant: racket-reloadable. p.p.s. Whatever workflow you decide on, as long as Racket supports it cleanly, I'm still glad to look at how Racket Mode could better support that workflow.

[image] alexsh: I need to be able to re-define in a module-aware manner (i.e. the way it works in CIDER for Clojure). Can you elaborate for us that don't know CIDER nor Clojure?

In case you don't find anything better: [image] Image-Based development and Interactive Experience racketGeneral @ungsams Is there something that allows to recompile just specific parts of the code without re-compiling everything? Here is a proof-of-concept. Put the following in a file "defun.rkt". Whenever you expect you will need to redefine a function, use defun instead of define. Then in the repl, you can use defun to redefine the function. Other functions referring to the function will pick up the new definition. defun.rkt #lang racket (provide defun) (define globals (make-hasheq)) (defin…

[image] soegaard: Can you elaborate for us that don't know CIDER nor Clojure? Sure. Clojure is a Lisp hosted on JVM (and other runtimes). CIDER is a Emacs package that provides integration with Clojure in a similar fashion to what racket-mode does. It also starts a REPL with which you can interact either directly from a buffer, or by sending expressions to it. The difference is in how namespaces/modules are treated. In CIDER if I am visiting a certain file (and thus, Clojure namespace, as there is 1:1 correspondence), sending a form or expression to the currently active REPL session is namespace-aware, such that it affects the definition in that namespace. This is what I expected from racket-mode, but it doesn't seem to work that way. Instead, the currently active module gets the definition updated, not the one I am visiting.

Racket modules are by design more static. It allows better optimization (inlining for one). However, all the bits and pieces are there to built a more dynamic approach. All it takes is a bit of indirection. You can do something like, what I linked to. Or you can use Racket namespaces to store the functions you need to redefine. Using your own versions of #%top and #%app you can make this seamless. The other option is the one mentioned by Greg. Figure out a way to make game state persistent. If the repl in, say, racket-mode keeps an namespace for redefinitions untouched then modules can store the game state outside the module (whose state disappears when the module is reevaluated).

Thanks for the suggestions so far, everyone — I will definitely have a look and give them a try! I think I owe you a slightly longer explanation of what I meant by "state" or "game state". Certainly, I am going to need to implement persistence of the game state the player cares about, such as their actual game progress, that should be able to survive restarting the game. For now, however, I am only working on the UI framework and this is where being able to reload just the bits I actually changed is crucial for rapid development. For example, this UI features dialog windows that may pop from one another up to 5 levels deep or more. Without proper reloading, I have to go through the whole sequence of opening these windows one after another for any small adjustment I make in the code of the deepest-nested one to finally see the effects of said changes. I actually started prototyping this game (engine) in Python, but I've outgrown its limited reloading capabilities rather quickly and was continuing purely by inertia up until now... I can share the link to the project, if there is interest and it's not against the rules here. :wink:

To get a prebuilt solution, I think the best bet is racket-reloadable, which Greg linked to. I think, the main use case is long running servers, but it might fit your use case too? racket-reloadable And do link to the game.

Video games seem to pop up quite often in the discussions around the hot-patching style of development. While I do appreciate the dangers of such style and I understand why Racket deliberately decided not to support it directly, I think some contained version thereof may be attainable and hope it will fulfill my needs for this project at least. :slight_smile: Here's the link (as I mentioned, it is still in Python, but I am starting re-implementing it in Racket as we are talking): GitHub - a1exsh/fhomm: Reimplementation of the game engine for "Heroes of Might and Magic" · GitHub

Someone replied to a topic you are Watching. [alexsh] | alexsh March 16 | | - | Originally asked here: Send to REPL and multi-module projects · Issue #766 · greghendershott/racket-mode · GitHub Hi! I am starting a project where I will have many module files, but it seems that "send to REPL" functions are not module-aware, or am I just missing some detail? Given the following two files: mod1.rkt: #lang racket/base (require "./mod2.rkt") (define t 1) and mod2.rkt: #lang racket/base (define t 2) I do racket-run while visiting mod1.rkt. Then I visit mod2.rkt and try to send the definition of t with racket-send-definition. It does succeed, but overrides the t from mod1. I'm not sure if this was addressed already, but Racket's REPL (assuming you sent the define lines) is one big "hopeless" namespace. It certainly supports modules, but the way that typically works is via require. You can use ,require-reloadable at a REPL to setup a reloadable module, but some things might not work well (e.g., changes to a struct will probably not work).

Send to REPL and multi-module projects

Questions & Answers

soegaard March 16, 2026, 1:59pm 4

In case you don't find anything better:

Topic		Replies	Views
Image-Based development and Interactive Experience General	36	959	May 24, 2025
DrRacket Workspaces? General drracket	16	574	July 3, 2023
Interesting discussion on hacker news (21-April-2024) General	15	898	May 14, 2024
Racket workflow feature comparison General	16	782	November 3, 2026
Racket v8.17 draft Release Notes Internals release-management	11	230	May 15, 2025

Send to REPL and multi-module projects

Related topics