"Marshall" <[EMAIL PROTECTED]> writes: > Matthias Blume wrote: >> >> How does this "create" such a problem? The problem is there in either >> approach. In fact, I believe that the best chance we have of >> addressing the problem is by adopting the "replace the code" model >> along with a "translate the data where necessary at the time of >> replacement". Translating the data, i.e., re-establishing the >> invariants expected by the updated/replaced code, seems much harder >> (to me) in the case of self-modifying code. Erlang got this one >> right. > > Pardon my ignorance, but what is the Erlang solution to this problem?
Erlang relies on a combination of purity, concurrency, and message passing, where messages can carry higher-order values. Data structures are immutable, and each computational agent is a thread. Most threads consist a loop that explicitly passes state around. It dispatches on some input event, applies a state transformer (which is a pure function), produces some output event (if necessary), and goes back to the beginning of the loop (by tail-calling itself) with the new state. When a code update is necessary, a special event is sent to the thread, passing along the new code to be executed. The old code, upon receiving such an event, ceases to go back to its own loop entry point (by simply not performing the self-tail-call). Instead it tail-calls the new code with the current state. If the new code can live with the same data structures that the old code had, then it can directly proceed to perform real work. If new invariants are to be established, it can first run a translation function on the current state before resuming operation. >From what I hear from the Erlang folks that I have talked to, this approach works extremely well in practice. -- http://mail.python.org/mailman/listinfo/python-list
