
Channels are Actors - carlehewitt
I highly recommend Simon Fowler&#x27;s ECOOP 2017 lecture <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=lpbkIjjoMRk" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=lpbkIjjoMRk</a><p>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&lt;T&gt;
      put[T] -&gt; Void,
      get[ ] -&gt; T<p>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&#x27;s lecture.<p>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 <a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;Inconsistency-Robustness-Studies-Logic-Hewitt&#x2F;dp&#x2F;1848901593" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;Inconsistency-Robustness-Studies-Logi...</a><p>To get the latest, see my upcoming Code Mesh Keynote: <a href="https:&#x2F;&#x2F;plus.google.com&#x2F;+CarlHewitt-StandardIoT&#x2F;posts&#x2F;BXSZ7Y25b4p" rel="nofollow">https:&#x2F;&#x2F;plus.google.com&#x2F;+CarlHewitt-StandardIoT&#x2F;posts&#x2F;BXSZ7Y...</a>
======
whalesalad
A 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?

~~~
carlehewitt
Fowler'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."

~~~
jchassoul
Do 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
Message passing communication is more fundamental than channel commutation.

However, lists {T*] of type T are very important; especially when they are
used with Futures.

------
carlehewitt
PS. 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.

------
jchassoul
How 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
The 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
Thanks professor, looking forward to join your keynote at code mesh.

[https://codesync.global/speaker/carl-
hewitt/](https://codesync.global/speaker/carl-hewitt/)

------
juancn
I assume you're referring to the Actor model actors not the constrained
implementations in popular frameworks, am I right?

~~~
carlehewitt
In 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.

------
rhizome
This appears to be a post about a mystery programming language.

~~~
jchassoul
Bigger than that is a concurrent model of computation!

~~~
carlehewitt
The Actor Model covers all digital computations. Actor programming languages
can express all computations in the Actor Model.

