Persistence and Memory

To support both debugging of complex tasks and distributed computing, we will need to provide object persistence – the ability to save an object or transfer it to a different process, generally by writing it to a file or database.Some languages offer built-in support for this, or have a sufficiently simple object model that a general-purpose persistence library can be built. In the Python language, for example, any object is essentially a nested hash table, and the "pickle" module provides object-to-file conversions for most objects. Erlang goes even further, with built-in concurrency and little distinction between persisted and in-process data. However, partly because of the constraints required to support this universality, these languages are not really suitable for our purposes.More general-purpose languages often come with libraries which support persistence of objects built within that library: examples include CL-STORE for LISP and MFC for C++.However, there are significant advantages to writing our own persistence methods, which as far as I am aware have not been replicated in any widely available library. Foremost among these is the automatic maintenance of documentation, just as for our generated public interface. Also, serialization is nearly conceptually identical to inspection, and we will support both without duplicative code.