Channels are Actors
However, channels are best understood as Actors with put and get messages so that aChannel.put[x] puts x in aChannel and aChannel.get[ ] gets from aChannel. A channel of type T has the following interface: Interface Channel<T> put[T] -> Void, get[ ] -> T
Actors can be categorically automatized, which means that up to a unique isomorphism, there is just one model that satisfies the axioms. In this way, Actors can be much more precisely defined in a general way than can be done using an extended lambda calculus as in Fowler's lecture.
Furthermore, a common misunderstanding is that an an Actor must have a mailbox, message queue, or event queue. There would be an infinite regress if any of these were required because since everything is an Actor, each of these would itself need a mailbox, message queue, or event queue. Instead, an Actor (e.g. a ReadersWriters scheduler) performs internal queuing when required. See https://www.amazon.com/Inconsistency-Robustness-Studies-Logi...
To get the latest, see my upcoming Code Mesh Keynote: https://plus.google.com/+CarlHewitt-StandardIoT/posts/BXSZ7Y...
What is the purpose of this post? To argue the academic definition of channels and actors? To spark a discussion on their uses and benefits?
The point of this post is to point out that channels are best understood as Actors that take put and get messages thereby achieving a unification in our programming languages and conceptual framework.
Of course, a channel can be conceived as a "living entity" and an Actor can be used as a "transit mechanism."
We can't have issues with channels if we're all actors and don't impedance mismatch the mixture when building our systems.
However, lists {T*] of type T are very important; especially when they are used with Futures.
To advertise Code Mesh:
> To get the latest, see my upcoming Code Mesh Keynote:
Interface ReadersWriter read[QueryRequest] -> QueryResponse, write[WriteRequest] -> Void
A ReadersWriter scheduler for a database allows multiple read messages to be concurrently operating in the database but a write excludes all others.
https://codesync.global/speaker/carl-hewitt/
Current implementations are inadequate :-(
There is a Silicon Valley startup working on one that should be adequate :-)