synit
/
synit-manual
1
0
Fork 0
Code Issues 2 Pull Requests Projects Releases Wiki Activity

Move message-as-a-derived-concept to the end, and comment it out

This commit is contained in:
Tony Garnock-Jones 2022-03-03 08:41:41 +01:00
parent 39bd40f4db
commit 8610673851
1 changed files with 15 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
src/syndicated-actor-model.md
View File

@ -66,16 +66,6 @@ shorter than their owning actors.
Local interactions, among objects (entities) within the state of the same actor, occur
synchronously. All other interactions are considered "remote", and occur asynchronously.
**"Message" as a derived concept.** A minimal theoretical Syndicated Actor Model includes
*only* assertion publication and retraction. Message transmission is excluded because,
theoretically, it can be *defined* as a "brief" assertion of the message body; that is, as an
assertion, followed "almost immediately" by a matching retraction. This naturally captures a
number of interesting properties of messages, including potential message loss and corruption
as well as issues related to medium access control. While it is useful theoretically to view
message exchange as a pattern (in the "software design pattern" sense) of assertion usage, the
pattern is so common in practical programming that the SAM and its implementations include
integrated support for messages as standard.[^analogy-with-function-call]
### Turns
Each time an event arrives at an actor's inbox, the actor takes a *turn*. [De Koster *et
@ -473,13 +463,26 @@ USENIX Annual Technical Conference. Boston, Massachusetts, 2012.
#### Notes
[^terminology-vs-e]: The terminology used in the SAM connects to the names used in E [[Miller
2006][]] as follows: our *actors* are E's *vats*; our *entities* are E's *objects*.
<!--
[^message-passing-derived]: A minimal theoretical Syndicated Actor Model includes *only*
assertion publication and retraction. Message transmission is excluded because,
theoretically, it can be *defined* as a "brief" assertion of the message body; that is, as
an assertion, followed "almost immediately" by a matching retraction. This naturally
captures a number of interesting properties of messages, including potential message loss
and corruption as well as issues related to medium access control. While it is useful
theoretically to view message exchange as a pattern (in the "software design pattern"
sense) of assertion usage, the pattern is so common in practical programming that the SAM
and its implementations include integrated support for messages as
standard.[^analogy-with-function-call]
[^analogy-with-function-call]: Consider the analogy to a similarly-fundamental design pattern:
function call. It can be usefully expressed in simpler terms, which expose interesting
aspects of and variations upon the pattern, but its utility makes it ubiquitous enough to
deserve special support not only from most programming languages, but from most *hardware*.
-->
[^terminology-vs-e]: The terminology used in the SAM connects to the names used in E [[Miller
2006][]] as follows: our *actors* are E's *vats*; our *entities* are E's *objects*.
[^rpc-sam-discussion]: Many variations on RPC are discussed in section 8.7 of Garnock-Jones'
[2017 dissertation][Garnock-Jones 2017] ([direct link to relevant section of online