But perhaps you meant mainly to suggest FSET as a method for avoiding shared mutable data? There should never be open mutation, even of the closure data. The safety of fully parallel concurrency can only be guaranteed by performing all mutations through BECOME which relies on a CAS operation in the dispatch threads.
I suppose you could get around that restriction with FSET. But then so could you with LOCKS and SEMAPHORES and all the other SMP primitives. Right now, as long as you abide by functional coding and BECOME as the only mutator, we can completely dispense with LOCKS, THREADS, SEMAPHORES, MAILBOXES. None of that is necessary at the user programmer level. You code as though you are the sole occupant of the machine. And so long as you abide by clean conventions, fully parallel concurrency is yours. The same code runs as well in a single thread, or on multiple cores and threads. Speed of execution is the only variable. > On Dec 22, 2025, at 12:11, Scott L. Burson <[email protected]> wrote: > > On Mon, Dec 22, 2025, 8:53 AM David McClain <[email protected] > <mailto:[email protected]>> wrote: >> >> https://github.com/dbmcclain/Lisp-Actors > > > This is very interesting! But I think it needs FSet > (https://github.com/slburson/fset) to store the state of an actor, and make > it easy to efficiently compute a new state which can be supplied to BECOME. > > -- Scott >
