edit: I dont reslly understand the downvotes, not trying to be rude or anything. Coming from CL the racket repl is very very barebones, it loses all state everytime you recompile. So I ask him how he deals with that coming from the very nice CL repl
edit: I dont reslly understand the downvotes, not trying to be rude or anything. Coming from CL the racket repl is very very barebones, it loses all state everytime you recompile. So I ask him how he deals with that coming from the very nice CL repl
You don't have to use DrRacket to use Racket.
People doing real work with Racket tend to have "workflow" setups that are closer to SLIME.
I personally used a simpler Emacs setup ("https://www.neilvandyke.org/quack/"), and ended up leaning more on modules and embedded unit tests ("https://www.neilvandyke.org/racket/overeasy/"), and less on very dynamic interactive evaluation like I'd done before.
Though, if you want to monkeypatch heavily, CL is famously good at that.
you can have a REPL in nvim/vim/tmux/screen/another terminal/or any other window , and send regions from your vim buffer to that repl
I have heard that this is not possible because Racket needs to make a stricgter separation of compile time and run time... but I am not sure whether this is actually true.
But, though I don't know current Racket internals, I'm not sure those need to be a barrier to monkeypatching that approaches CL.
Other than optimizations that make some debugging info and dynamic changes difficult-to-impossible, if the system had a mode to disable these optimizations (or to maintain some information in parallel that permits a cascading unraveling of optimizations affected by a change), I'm not aware of a fundamental reason the system couldn't support more loose poking at things.
Though, one implementation complication that Schemes do have is first-class continuations.