Interesting suggestion… 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.
But there are no rules, just conventions, used within my current Actors system. One convention is to provide a customer (Actor) argument in most messages. But again, no hard rules, just conventions. The most compelling advance from Conventional Hewitt Actors is the notion of transactional behavior which dictates that no SEND nor BECOME can be seen by anyone, including the issuer, until the behavior function exits cleanly. When parallel concurrent execution occurs, only one thread will succeed in committing the SENDS and BECOME. The others will be silently retried by redelivering their message to the (possibly now changed) Actor behavior. Writing code in such a system is a lot like assembling little Leggo blocks of behavior that can be stitched together to provide larger customizable behaviors to the outside world. Currently our hardware is aimed directly at Call/Return function behaviors, and so an Actors-all-the-way-down would be completely impractical on our present computers. I find Call-Return to be effective for the innards of math functions, and Actors to be most practical for high-level orchestration of components - as in the Async Socket interface. > 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 >
