From: <don...@is...> - 2009-02-26 18:56:46
|
Alessio Stalla writes: > For the non-Java-savvy, serialization is the capability ... The corresponding facility in lisp is called print and read, though I would not characterize the external representation as "binary". Compile-file often uses its own form of print/read with an external representation that I would call binary. In the general case, where there may be shared structure, you have to print with *print-circle* bound to T. So one test would be to try to serialize a circular list. > 1. that the whole Lisp world can be reached by iterating over all > symbols in all packages? This is really the same question as what the garbage collector has to find. You don't have to save garbage. In fact, save-image typically also does a GC. If you want to save a state with running programs then you also have to save the stacks, which can refer to objects that are not otherwise accessible. Other than that I think the list of packages is adequate. Of course, the lisp implementation might have its own internal data. > 2. that the whole Lisp world can be restored overwriting the > value/function cells of all symbols in all packages (maybe except the > COMMON-LISP package and other built-in packages)? The built in packages can be changed, as can the symbols in them, so you certainly have to save those too. > 3. that (compiled) closures can be easily dumped/restored? (I imagine > they can, since probably they are already stored in fasls?) Yes, but please note that these can also share structure with other things. In fact, pretty much everything can share structure with everything else. This is why you have to do what amounts to one single print of the world with *print-circle* T. |