This helps a lot, thank you. Your arguments help me to understand how I
fail to communicate to others what I see in actor systems. Finding a way to
address the concerns you bring up will go a long way for my ability to
communicate what I see.
>From their definition, I can "know" that a single actor will terminate
> (i.e. finish processing a message), without ever receiving a response.
The problem with this, that I see, is that (I'm going to jump way up in the
layers of abstraction) in my physics view of actors, that's similar to
saying "I 'know' that the value was committed to a database, because I told
it to 'put'". I won't know unless you receive an 'ack' (whatever that 'ack'
is, in dynamo it could be after reaching quorum, etc.). Jumping back down
in layers of abstraction. Imagine an actor, the sole responsibility of
which, is to store a single value. I send a {save 7} message to it. I
"know" that it has 7... well.. sort of. I won't know until I send something
like {read} and receive a response. This is that frame of reference thing
I've been describing. Messages could be lost.
Going back to idea of global knowledge that an actor will terminate. Well,
yes, but I will only "know" that, if it responds to another message.
Because if I never send another message to it, then that actor is not
relevant to the system anymore, it effectively becomes a "sink" behavior, a
"black hole."
important for safe concurrency within an actor.
This is another hint that we might have a different mental model. I don't
find concurrency within an actor interesting. Actors can only process one
message at a time. So concurrency is only relevant in that sending messages
to other actors happens in parallel. That's not an interesting property.
Do you really avoid all such reasoning? Or is such reasoning simply at a
> level that you no longer think about it consciously?
Actor behavior is a mapping function from a message that was received to
creation of finite number of actors, sending finite number of messages, and
changing own behavior to process the next message. This could be a simple
dictionary lookup in the degenerate case. What's there to reason about in
here? In my view, the properties of how these communicate are the
interesting parts.
A fact is that programming is NOT like physics,
This is a description of your opinion of "best practice" of how to program.
It's an assertion of a preference, not a proof. I believe this is the main
difference in our points of view. I like actors precisely because I CAN
make programming look like physics. A reference frame is really important
in thinking about actor systems. Assuming, or worse, relying on global
knowledge when designing an actor system seems, to me, not to be the
"right" way (unfortunately I cannot readily point to a proof of that
last sentence so I acknowledge it as an unproven assertion, but it's where
my intuition about actors currently points me :/ , I'll need to do better)
It is this frame of reference that supports abstraction, refactoring,
> static typing, maintenance, optimizations, orthogonal persistence, process
> control (e.g. kill, restart), live coding, and the like.
I think this highlights our different frames of reference when we discuss
actor systems. Refactoring, static typing, maintenance, optimizations, etc.
are language level utilities... what language an actor system is written in
is, in my opinion, an "implementation detail". It's relevant in a
productivity sense, but because actor behaviors should/are simple, that's
not the interesting part of the actor system. Another way of putting it,
actor model is a pattern, not a language. Notice how many actor libraries
there are in all the different languages. Most of the languages I work in,
I build an actor library for. After doing this a few times, there is a
clear distinction between the actor model and an implementation in a
language. For completeness, there are also actor languages, but that's
"just" taking the pattern "all the way down" because the model is powerful
if viewed from a certain point of view. Abstraction, maintenance,
optimizations, process control, live coding, etc... fit in as tools in my
view of the actor model as a running system.
Also, individual actors often aren't decomposable into actor configurations
In the physics point of view of programming actors, it's impossible to tell
the difference. Why would you want to decompose something that is already
encapsulated?
So, I think I've arrived at a realization, which I hinted above (perhaps
you've already seen this and I'm just now catching up). I think I'm
describing an actor model as in "turing machine/a model of computation" (a
running system of actors communicating via messages, the "platonic form" of
it, if you will), whereas you're describing an actor model as in
"language". Do you think that correctly frames our discussion so far?
I think we might have interesting things to talk about within the confines
of an actor _language_, but we should make a clear distinction about
expressiveness and properties of a language, vs. those of an actor model of
computation. Perhaps you're describing problems with the "platonic" model
that are hard to express in an "implementing" language, and I haven't
grokked this point until now? I'm very much interested in hearing about the
"systemic problems of actors" because I'd like to figure out any solutions
for such from my physics perspective on the problem.
As a side note, I think this still falls into Layering, Thinking and
Computing. But perhaps if we take this further it ought to be a different
thread?
On Mon, Apr 8, 2013 at 6:51 PM, David Barbour <[email protected]> wrote:
> On Mon, Apr 8, 2013 at 2:52 PM, Tristan Slominski <
> [email protected]> wrote:
>
>> This is incorrect, well, it's based on a false premise.. this part is
>> incorrect/invalid?
>>
>
> A valid argument with a false premise is called an 'unsound' argument. (
> http://en.wikipedia.org/wiki/Validity#Validity_and_soundness)
>
>
>>
>> What does it mean for an actor to "terminate". The _only_ way you will
>> know, is if the actor sends you a message that it's done.
>>
>
> That is incorrect. One can also know things via static or global knowledge
> - e.g. type systems, symbolic analysis, proofs, definitions. Actors happen
> to be defined in such a manner to guarantee progress and certain forms of
> fairness at the message-passing level. From their definition, I can "know"
> that a single actor will terminate (i.e. finish processing a message),
> without ever receiving a response. If it doesn't terminate, then it isn't
> an actor.
>
> In any case, non-termination (and our ability or inability to reason about
> it) was never the point. Composition is the point. If individual actors
> were allowed to send an infinite number of messages in response to a single
> message (thus obviating any fairness properties), then they could easily be
> compositional with respect to that property.
>
> Unfortunately, they would still fail to be compositional with respect to
> other relevant properties, such as serializable state updates, or message
> structure.
>
>
>
> Any reasoning about actors and their compositionality must be done in
>> terms of messages sent and received. Reasoning in other ways does not make
>> sense in the actor model (as far as I understand).
>>
>
> Carl Hewitt was careful to include certain fairness and progress
> properties in the model, in order to support a few forms of system-level
> reasoning. Similarly, the notion that actor-state effectively serializes
> messages (i.e. each message defines the behavior for processing the next
> message) is important for safe concurrency within an actor. Do you really
> avoid all such reasoning? Or is such reasoning simply at a level that you
> no longer think about it consciously?
>
>
>>
>> there is no privileged frame of reference in actors, you only get messages
>>
>
> I'm curious what your IDE looks like. :-)
>
> A fact is that programming is NOT like physics, in that we do have a
> privileged frame of reference that is only compromised at certain
> boundaries for open systems programming. It is this frame of reference that
> supports abstraction, refactoring, static typing, maintenance,
> optimizations, orthogonal persistence, process control (e.g. kill,
> restart), live coding, and the like.
>
> If you want an analogy, it's like having a 3D view of a 2D world. As
> developers, often use our privilege to examine our systems from frames that
> no actor can achieve within our model.
>
> This special frame of reference isn't just for humans, of course. It's
> just as useful for metaprogramming, e.g. for those 'layered' languages with
> which Julian opened this topic.
>
>
>> Actors and actor configurations (groupings of actors)
>> become indistinguishable, because they are logically equivalent for
>> reasoning purposes. The only way to interact with either is to send it a
>> message and to receive a message.
>>
>
> It is true that, from within the actor system, we cannot distinguish an
> actor from an actor configuration.
>
>
>
> "It's Actors All The Way Down."
>>
>
> Actors don't have clear phase separation or staging. There is no "down",
> just an ad-hoc graph. Also, individual actors often aren't decomposable
> into actor configurations. A phrase I favored while developing actors
> systems (before realizing their systemic problems) was "It's actors all the
> way out."
>
>
> _______________________________________________
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc
>
>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
