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