| I am the author of Hotcaml. There is actually some notion of persisting state in it. Reloading is done at the granularity of a module. The reverse dependencies of a module that changed are also reloaded, but the dependencies are not. The runtime state of all modules that are not reloaded is persisted. Here is an example: https://aws1.discourse-cdn.com/standard11/uploads/ocaml/orig... The dependency graph is roughly: system layer -> renderer -> slideshow
The system layer initializes the window (with SDL) and an OpenGL context.
The renderer allocates resources (buffers, fonts, ...).
The slideshow only defines the content to be drawn. In the live code, only the slideshow is modified, so the system and renderer states are not affected. Doing reloading at the module granularity meshes well with ML semantics: it is a straightforward extension of the "hyperstatic environment" and it preserves type safety and modular abstraction. A static language that is designed with hot reloading in mind could do better, the generative nature of ML type definitions is not ideal. I guess that structural type systems permit a finer grained notion of reloading. Actually, a finer-grained notion of persistence and state migration could be built as a library (with some macros) on top of Hotcaml. The important step is to be able to reify type definitions and then to define some notion of "type compatibility" (between old and new modules) by induction on the structure of types.
This is a lot of work, but could be built on top of Hotcaml foundations. |
Ah that makes sense to me, and explains to me why in your linked demo the rotation resets after every color change, but the other stuff doesn't. That does mean though that having the circle not reset after every color change is probably not feasible unless the module order is fairly convoluted right? (because most straightforward ways I can think of organizing the code would have the circle motion as a reverse dependency of the color of the circle).