Open dhil opened 5 years ago
Do you intend this as a development convenience only, i.e. equivalent to running Links as a subprocess of a watchdog process that monitors app.links
(and all its dependencies?) and just kills Links and restarts it whenever app.links
changes?
Or as a (robust) feature that one would want to use in a real setting? The latter would be much more involved; I think the former could (should?) be a Python script or something if we want it. Implementing the former within Links would likely trip over stateful parts of in Links that assume a single parse-typecheck-translate-interpret pipeline, starting with #314. (Not that fixing these would be a bad thing).
I envisage it as being supported by the Links implementation, initially as a crude whole restart of the application for development convenience. The Python-script approach may be sufficient for this. I think fine-grained hot reloading of individual modules in a production setting is a whole other ball park (nevertheless an interesting one), and I bet it invites a whole series of (open) research questions.
And I agree, it is likely to be an involved change.
There is a whole line of work (some PL based) on hot-swapping/upgrading of running systems, yeah. I'm not sure there are major open questions about how to do it in general as opposed to in Links specifically, but the latter would certainly be a nontrivial project.
It would be great if the Links appserver were capable of performing hot reloading. For example, running
./links --hot-reload app.links
should then attempt to recompileapp.links
whenever the source code changes.The hot reload loop should be robust enough to handle compile time errors and runtime errors.