An Actor sending a message to itself
Carl Hewitt
Today at FriAM there was discussion of issues involved where
an Actor holding its region of mutual exclusion sends a message to itself.
Issues include the following:
- Why would an Actor release its region of mutual exclusion when it could just process the message without releasing.
- Should the Actor abstraction have a special axiom for messages sent to itself?
- What happens when while holding the region of mutual exclusion, an Actor in parallel sends two messages to itself?
Cheers,
Carl
https://professorhewitt.blogspot.com/
Terry Hayes
Counting :[ ]→Interface go→Void, stop→Natural ≡
[ ] ↦↦ // constructor has no arguments
count := 0, // The variable count is initially 0
continue := False| // The variable continue is intially False
go ↦ // When a go message is received:
continue cases // Cases continue for are as follows:
True then // If continue is True,
count := count+1; // then increment count and afterward
Hole (This Counting)∎go // in a hole in the region of mutual exclusion,
// send a go message this instance of Counting
False then Void // If continue is False, then return Void
stop ↦ // When a stop message is received:
continue := False; // Assign continue the value False and then
LET counting_beh(value) = \msg. [
CASE msg OF
#go: [
SEND #go TO SELF
BECOME counting_beh(add(value, 1))
]
(#stop, cust): [
SEND value TO cust
BECOME \msg. []
]
END
]
CREATE actor WITH counting_beh(0)
SEND #go TO actor
SEND (#stop, println) TO actor
Notice the SEND TO SELF on line 4.
Terry
------
NOTES:
The Humus simulator doesn't have enough arbitrariness in message delivery to demonstrate fully. It tends to process three messages: #go, (#stop, cust) and #go; in that order.
I've replaced the case analysis in Carl's code by new behavior for the actor. I think this is an advantage of having functional capabilities together with the BECOME statement (effect).
I believe the "Hole (This Counting).go" in Carl's version waits for a response before continuing. I'm using a "fire and forget" version of the "go" message. I've always been concerned that Carl's version might accumulate "continuations" which then reacquire the region of mutual exclusion, and then do nothing. This can probably be optimized away by the compiler.
--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/BY5PR10MB4274A05DD45E251718F4EB5AD93B9%40BY5PR10MB4274.namprd10.prod.outlook.com.
Carl Hewitt
Probably worth noting that the counting example is an exercise in
providing a minimal example to illustrate inadequacies of Nondeterministic Turing Machines.
The example is not an illustration of good practices to use in applications.
Regards,
Carl
https://professorhewitt.blogspot.com/
PS. The Humus example below is somewhat special case because
Humus is built on 1-way messaging.
Current generation applications mainly using request-response.
Always requiring explicit customers leads to long string-bean style code :-(
Also worth noting that Humus is not strictly speaking an Actor programming language because
it is not the case that everything is an Actor.
For example, the lambda expressions (for behaviors) are not Actors.
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAGLSb_XgR17WNmTyHTFFnYs_o6OyHXOad2tyWPfDcyG-38K2Pw%40mail.gmail.com.
Carl Hewitt
PS. Would be interesting to see if Humus can be upgraded to be a true Actor programming language ;-)
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/BY5PR10MB42742AB36392980C7B7A1A6FD9399%40BY5PR10MB4274.namprd10.prod.outlook.com.
Dale Schumacher
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/BY5PR10MB4274197DD8B3F0611CFEB409D9389%40BY5PR10MB4274.namprd10.prod.outlook.com.
Carl Hewitt
Dale,
Thanks for your interesting Humus language experiment :-(
It is very important not to confuse a programming language with
the Actor mathematical model which is the unique model up to a unique isomorphism of the theory Actors.
See the following: https://papers.ssrn.com/abstract=3418003
In a pure Actor programming language, everything is an Actor including
the binding of every identifier and the result of every expression.
Mixing up a programming language with an (axiomatic) specification of a programming language may be less than optimal.
Regards,
Carl
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAPeSZfD5333HgW3gGb_chBPWGuRotxGzww9ah4U8YEBj%2Be%3D2sQ%40mail.gmail.com.
Carl Hewitt
Sent: Monday, June 7, 2021, 14:29
To: fr...@googlegroups.com
Subject: RE: FW: [friam] An Actor sending a message to itself
Mark S. Miller
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/BY5PR10MB427479E43991026ED9F60FD5D9389%40BY5PR10MB4274.namprd10.prod.outlook.com.
Carl Hewitt
PS. In other words, if a pure Actor programming language has first-class expressions for “behaviors”, then a “behavior” must be an Actor.
From: Carl Hewitt
Sent: Monday, June 7, 2021 14:30
To: fr...@googlegroups.com
Subject: RE: FW: [friam] An Actor sending a message to itself
Dale,
Thanks for your interesting Humus language experiment :-)