Re: Concurrency via isolated process/thread

[Gregory Heytings]

> > I don't believe any useful Lisp program in Emacs can be 
> > side-effect-free, for the purposes of this discussion.  Every single 
> > one of them accesses the global state and changes the global state.
>
> As I said, I hope that we can convert the important parts of the global 
> state into thread-local state.

That's not possible alas.  Basically Emacs' global state is the memory it 
has allocated, which is an enormous graph in which objects are the nodes 
and pointers are the edges.  Any object may be linked to any number of 
other objects (which means that you cannot isolate a subgraph, or even a 
single object, of the graph), and any non-trivial Elisp function (as well 
as garbage collection and redisplay) can change any of the objects and the 
structure of the graph at any time (which means that two threads cannot 
use the same graph concurrently without both of them taking the risk of 
finding the graph suddenly different from what it was during the execution 
of the previous opcode).

Given that, the only thing can be done in practice (which is what 
emacs-async does) is to create another Emacs instance, with another global 
state, in which some processing is done, and report the result back to the 
main Emacs instance.

The only alternative is to create another Emacs from scratch, with 
concurrency as one of its design principles.

> > > Yes. I mean... look at Haskell. There is no shortage of pure 
> > > functional libraries there.
> >
> > I cannot follow you there: I don't know Haskell.
>
> In short, pure functions in Haskell can utilize multiple CPUs 
> automatically, without programmers explicitly writing code for 
> multi-threading support.

The problem is that Elisp is not Haskell, and cannot be converted into 
something that resembles Haskell.  Haskell functions are pure by default 
(impurity is the rare exception), Elisp functions are impure by default 
(purity is the rare exception).