4 ms·
Channels are Actors
I highly recommend Simon Fowler's ECOOP 2017 lecture https://www.youtube.com/watch?v=lpbkIjjoMRk https://www.youtube.com/watch?v=lpbkIjjoMRk
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-Logic-Hewitt/dp/1848901593 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/BXSZ7Y25b4p https://plus.google.com/+CarlHewitt-StandardIoT/posts/BXSZ7Y...
- whalesalad 8y agoA channel can behave like an actor but they are not the same thing. An actor is a living entity. A channel is a transit mechanism. 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?
- noblethrasher 8y agoIt's worth noting that the submitter of the post is also the inventor of the Actor Model.
- carlehewitt 8y agoFowler's talk addressed issues arising from "mixing metaphors" by having both channels and Actors in our programming languages. 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."
- whalesalad 8y ago"Actors that take put and get messages" – makes sense.
- jchassoul 8y agoDo you want to abolish the protagonist role of the channel abstraction like in CSP based languages and certain message brokers? We can't have issues with channels if we're all actors and don't impedance mismatch the mixture when building our systems.
- carlehewitt 8y agoMessage passing communication is more fundamental than channel commutation. However, lists {T*] of type T are very important; especially when they are used with Futures.
- zokier 8y ago> What is the purpose of this post? To advertise Code Mesh: > To get the latest, see my upcoming Code Mesh Keynote:
- carlehewitt 8y agoYou can watch the keynotes for free after the conference :-)
- carlehewitt 8y agoPS. The interface for ReadersWriter is 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.
- rhizome 8y agoThis appears to be a post about a mystery programming language.
- jchassoul 8y agoBigger than that is a concurrent model of computation!
- carlehewitt 8y agoThe Actor Model covers all digital computations. Actor programming languages can express all computations in the Actor Model.
- jchassoul 8y agoHow this view on channels relate with information theory? can we think of them as an actor and its capacity a property of the physical modeling represented by that actor: floppy disk, cd, dvd, lan, wan, river, lake, ocean?
- carlehewitt 8y agoThe relationship with theories of information is explained in Strong Types for Direct Logic here: https://hal.archives-ouvertes.fr/hal-01566393 https://hal.archives-ouvertes.fr/hal-01566393
- jchassoul 8y agoThanks professor, looking forward to join your keynote at code mesh. https://codesync.global/speaker/carl-hewitt/ https://codesync.global/speaker/carl-hewitt/
- juancn 8y agoI assume you're referring to the Actor model actors not the constrained implementations in popular frameworks, am I right?
- carlehewitt 8y agoCorrect. Current implementations are inadequate :-( There is a Silicon Valley startup working on one that should be adequate :-)
- carlehewitt 8y agoIn almost all current frameworks. every Actor has a mailbox. It makes very good sense for an Actor programming language not to have mailboxes built into every Actor because it can make programs less robust, more difficult to understand, and more difficult to optimize. Instead, when desired an Actor can do its own internal queuing as necessary.