Actor-State is just an experimental implementation at this time. There are only a few example where I tried using a formal Actor-State. One of them is my implementation of a Key-Value store (kvdb). The other place is in my Ionosphere monitoring system where I track 15 MHz carriers to <100 μHz precision.
I did this implementation because a friend of mine involved in Actors machines suggested the JavaScript JSON Dictionary - which I find to be enormously redundant and noisy. Just a simple PList with keyword keys could fully replace them and great simplification. And so my Actor-State was an attempt to prove that out. I fear that Purely Functional Red-Black Trees would be even more costly, but maybe not. I should look into it, or your FSet. > On Dec 22, 2025, at 17:19, David McClain <[email protected]> > wrote: > > I guess the specific example of my Actor-State does have an ordering > relation, since the keys are all keyword symbols. So good point on that O(log > n). My simple implementation is just a copy / replace, which is O(n). > > > >> On Dec 22, 2025, at 17:16, David McClain <[email protected]> >> wrote: >> >> Yes, good points O(log n) cost. But that implies that elements have an >> ordering relation, no? Partial or total order. I have such structures that I >> use often, red-black trees that are purely functional implementations. So I >> understand your points here. But many times my data does not have any order >> relation, just an equality. >> >> >> >>> On Dec 22, 2025, at 15:52, Scott L. Burson <[email protected]> wrote: >>> >>> On Mon, Dec 22, 2025, 12:20 PM David McClain <[email protected] >>> <mailto:[email protected]>> wrote: >>>> >>>> > BECOME takes a functional closure, which contains its state within the >>>> > closure vars. But I have become frustrated with too many BOA args, and I >>>> > also implemented a kind of dictionary to carry state with items labeled >>>> > by a keyword. >>> >>> >>> Right. I saw your file 'actor-state.lisp' and thought "Ah! This is a >>> functional map. This man needs FSet." >>> >>> Yes, the state is in the closure vars, but that doesn't preclude it being >>> large and complex. With functional data structures, you can efficiently >>> prepare an updated version of a large structure without invalidating the >>> previous version. If something goes wrong before the BECOME takes effect, >>> no harm has been done; the tentative new version simply becomes garbage. >>> The trick is to use only O(log n) space each time, where n is the size of >>> the previous version. >>> >>> -- Scott >>> >> >
