Jack Harper wrote:
...an interesting idea.
Years ago (1984), I had dinner with Nils Nilsson (AI pioneer) and he mentioned the idea that he wanted to build a system that once alive would never be powered down again - in his view a minor but necessary prerequisite of an AI system.
It will be interesting to see what people will say about how to do this.
This is so interesting that I would like to answer it. I apologize for the fact that none of this has anything to do with Lisp per se.
What if the machine breaks or there is a power failure?
There has been some great work, I believe done cooperatively by Stanford and U.C. Berkeley, about how to deal with this. Do a web search for "crash-only systems". What you have to do is be able to quickly recover from such failures, getting you back to the same state you were in, or at least that latest state that you decided to checkpoint. Tecnology developed for database management systems is very helpful here. Some of the more recent Linux file systems have this property, ususally implemented by what DBMS people call redo-logging.
Bear in mind, though, that one reason people "reboot" things is because they *want* to get rid of the state, rather than to recover it! But *which* state should be reset and which should not? In traditional systems, some state is persistent, which means stored in places like files or DBMS's (or servers, sometimes), and the rest is "transient" and gets reset on a reboot.
Doing this is very crude. It just arbitarily does things like setting global variables to NIL or whatever their initial value was. Why do you think *that* is a particulary good thing to do? Well, it has something to do with the application programmer's *reason* to decide what to store in a file/DBMS and what not.
In the crash-only system, the good side is that you can control this: you can just call a function that resets whatever state you want to not preserve.
The drawback is that you might not succeed in enumerating all the ones that you'd like to see reset. So you might want to do something like putting a declaration on those things that you'd like to see reset (at those times when you otherwise would have done a reboot).
At this point, you may notice that traditional and crash-only systems are not as different as they initially appeared.
I should think about this more and make it a blog post, but first run it by the crash-only guys...
-- Dan