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 <dbm@refined-audiometrics.com> 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 <dbm@refined-audiometrics.com> 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 <Scott@sympoiesis.com> wrote:
On Mon, Dec 22, 2025, 12:20 PM David McClain <dbm@refined-audiometrics.com <mailto:dbm@refined-audiometrics.com>> 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