Re: Elisp containers

[Tom Tromey <tom@tromey.com>]

>>>>> "Vladimir" == Vladimir Sedach <vas@oneofus.la> writes:

Vladimir> One way to solve the problems of "which environment to start from?"
Vladimir> and expensive copying is to implement environments as a fully
Vladimir> persistent (AKA purely functional) table. This will let you do
Vladimir> roughly the equivalent of fork(2) in a single address space quickly
Vladimir> (with the real cost amortized over the whole system).

One other consideration in this case is that one must apply the changes
to the actually existing Emacs.  Reading the portable dumper thread or
the variable binding code makes this seem less possible.  Though perhaps
I am pessimistic.

Vladimir> Virtualizing the environment with a shared heap is an IMO interesting
Vladimir> idea that has not been well explored yet, but it requires a very
Vladimir> different approach to Lisp system functions (they will all have to be
Vladimir> based around immutable data structures)

I should have mentioned immutable data structures.  This seems like a
difficult change as well.

In practice I guess I would not worry too much about existing elisp
code.  Probably if one is reaching for threads or containers, one is
willing to adapt one's code to immutability as well.

But I wonder how it would be implemented.  Tag bits are in short supply
and there isn't leftover space in a cons for a flag AFAIK.  Other types
might not be as troublesome.

>> Finally, this approach greatly reduces debuggability and the ability to
>> mess around.  Emacs would no longer be an open system -- threads would
>> have private data and there would be no way to access that.

Vladimir> The debugger could point to the environment of the thread from which
Vladimir> it was invoked. The same could be done for REPLs. So the whole
Vladimir> tool set would have to be changed to accommodate this virtualization.

Thanks, this is a nice idea.

Tom