> I've reached the conclusion that if you have first-class functions and the > ability to create FIFO queue classes, you have everything you need. You don't > need Go channels, or operating system threads, etc. Those are just > inefficient, Greenspunian implementations of a simpler idea. In fact, you can > draw diagrams of Software LEGO parts, as mentioned by dbm, just with draw.io > and OhmJS and a fairly flexible PL. [I'd be happy to elaborate further, but > wonder if this would be appropriate on this mailing list]
This is essentially what the Transactional Hewitt Actors really are. We use “Dispatch” threads to extract messages (function args and function address) from a community mailbox queue. The Dispatchers use a CAS protocol among themselves to effect staged BECOME and message SENDS, with automatic retry on losing CAS. Messages and BECOME are staged for commit at successful exit of the functions, or simply tossed if the function errors out - making an unsuccessful call into an effective non-delivery of a message. Message originators are generally unknown to the Actors, unless you use a convention of providing a continuation Actor back to the sender, embedded in the messages. An Actor is nothing more than an indirection pointer to a functional closure - the closure contains code and local state data. The indirection allows BECOME to mutate the behavior of an Actor without altering its identity to the outside world. But it all comes down to FIFO Queues and Functional Closures. The Dispatchers and Transactional behavior is simply an organizing principle. - DM
