Yeah.. that came up in a private conversation as the easiest next step for global "workspaces" like the R repl has. There' s still perhaps some trickiness if any objects contain pointers to other objects since pointers are not "fat" (or encoded as offsets to some base address to be "re-linked at load time"), but global numbers. So, you probably need to remap the data to the same VM address it had before (which is easier to demand on 64-bit systems, but not all OSes support this kind of thing, but portability may be less critical for a REPL, etc., etc. ).
If it helps @Niminem conceptualize things, the program state problem is virtually identical to the problem of .DLL/.so shared libraries but with ["pre-compiled" data instead of/as well as pre-compiled object code](https://en.wikipedia.org/wiki/Von_Neumann_architecture). Old Lisp systems would just dump their entire memory image to disk for later reloading (this is surely what R workspace saving/loading was inspired by) and the GNU emacs build system still works this way today (though they recently added ".eln" ELisp-Native shared object files). What makes this easier (&so more common) for code is that being (mostly) up-front & read-only there is no shared mutable memory. Since data is under user semantics (not, e.g. Intel) and so more surgically editable than changing CPU instructions, people tend to reach more for edits (which DB people would complain about next, but devs can also be taught hazards, OSes/stdlibs can default to exclusive file access, etc.). * * * But also, @Niminem, the same private conversation also noted "data longer lived than the process" is sort of the easiest part of the problem. Most pithily, the "E" in R-E-P-L that is "the hard part" since to "evaluate" you want/need an expression interpreter/compiler and soon you want it to be "just like" AOT compiles (e.g. not just HCR/NimVM FFIs, but some knob to compile code that runs faster on a larger data sample once your logic is debugged). Then - boom! - you're back at incremental compilation (IC) to native code of some kind. So, I doubt having program state in files can itself solve the Jupyter Notebook IDE problem for Nim that began this thread. My recommendation for rapid development environments is usually to just use regular old editor buffers. ( [Everyone always wants faster compiles.](https://xkcd.com/303/) A first, easy step for faster compiles is [changing your nim.cfg from the factory default of -Og to -O0](https://forum.nim-lang.org/t/8677#56724); PRs to get more Nim-science libs working with `tcc` could yield more. On some CPUs/C-compilers-compling Nim, [PGO of the compiler itself is said to help](https://forum.nim-lang.org/t/10128). Etc., etc. This is an oft-discussed topic in the Forum.)
