Actor Principles, Complexity and Class Count

[AristosQueue (NI)]

Daklu wrote:

What else could you do? 

*head bang*

*deep breath*

Please, for the love of sane communication, stop muddling the subject. This is the Actor Framework discussion forum. If you are going to talk about non-AF actors, you have two options: either use the phrase "non-AF actor" in all references or take the discussion to  another forum. Without modification, in this forum, the word "actor" means Actor  Framework.lvlib:Actor.lvclass.  Your continued insistence on talking about non-AF actors in this forum context just confuses the entire conversation.

I answered the question for actors. Meaning AF actors. No attribution needed.

[AristosQueue (NI)]

Now, as for non-AF actors... I don't see how changing the communications channel (to a stack, or to a last value or to a multipath system) would in any way change those non-AF actors from being QSMs.

The stack is just a queue where the sender is enqueuing at the opposite end.

The last value is just a lossy queue.

The multipath is still a queue with a different delivery mechanism.

The important part is that "messages are sent (somehow), the actor waits for a message, it acts on the message, updates its state, then goes back to waiting on a message." That's a QSM. To make any actor that is not a QSM, you would need to do one or more of the following:

1. have something reach in from the outside to change its state (for example, share its state through a DVR with some other process) or
2. allow the actor to look through the queue'd messages sent and pick and choose the messages it wants to act on

The second cannot be done with AF. The first can be done but is frowned on. With non-AF actors, both might be possible, but both would be rejected by all non-AF actor systems that I've seen.

Daklu wrote:

(Like macros, enqueuing priority messages in front, having the loop enqueue messages to itself, etc.)

All of which are possible with AF actors. Macros are Batch Msg. The Enqueuer has priorities. And actors FREQUENTLY send messages to themselves.

[Daklu]

AristosQueue wrote:

Please, for the love of sane communication, stop muddling the subject...  Your continued insistence on talking about non-AF actors in this forum context just confuses the entire conversation.

Wait, what?

You posed the question, "What else could you do other than a QSM?" that, to my eyes, appears to be a theoretical question about other possible ways of constructing a message handling loop in *any* actor--AF or not.

I apologize if I misunderstood the context of your question, but I don't see any other way to interpret what you said.  The question "what else could you do" is non-sensical in a context restricted to the current AF implementation--we can't do anything else because the AF implements the MHL and doesn't provide users with a way to replace it.

Perhaps you can clarify your comment?

AristosQueue wrote:

Now, as for non-AF actors... I don't see how changing the communications channel (to a stack, or to a last value or to a multipath system) would in any way change those non-AF actors from being QSMs.

I'm calling a foul for inconsistancy.  In previous discussions where we have talked about what QSM means, I've raised the point that the queue is entirely incidental to the functioning of the construct.  It could be replaced with an array, or a file system, or some other arbitrary data structure.  It was pointed out to me (correctly, imo) that "queue" refers to the FIFO behavior of the message transport, not the implementation.  Now you seem to be saying the Q part of QSM refers to the implementation.  Choose one--implementation or behavior.  You can't have it both ways.

AristosQueue wrote:

The stack is just a queue where the sender is enqueuing at the opposite end.

...

You are confounding behavior and implementation.  Yes, a stack (abstract data structure) can be implemented using a queue (Labview primitive type,) but a stack (abstract data structure) is NOT just a queue (abstract data structure) with the minor difference of enqueuing at the opposite end.  Where items are enqueued is central to the definition of what queues (abstract data structures) and stacks (abstract data structures) are.  Queues (abstract data structure) are FIFO.  Stacks (abstract data structure) are LIFO.

Saying "the stack is just a queue..." is a bit like saying "a dog is just a crocodile with slightly different DNA, so I'm going to call that place where my dog Fido lives a crocodile house."  The differences between a dog and a crocodile are far more important than the similarities in this context.  People get the wrong impression when you talk about the crocodile house in your backyard.

AristosQueue wrote:

The important part is that "messages are sent (somehow), the actor waits for a message, it acts on the message, updates its state, then goes back to waiting on a message." That's a QSM.

We already know the "SM" part of QSM implementations is almost never accurate, and now you're making the Q part optional as well.  Names matter.  At what point does this construct you are claiming is a QSM, which may or may not have queue behavior and may or may not be a state machine, no longer retain the right to be called a Queued State Machine?

I know you want everyone to adopt your definition of QSM, but the simple truth is the larger Labview community doesn't ascribe the same meaning to QSM as you do.  Communication is hampered when parties use the same terms to describe different concepts.  (See this comment re: orangutans.)  So please, for the love of sane communication, stop muddling the subject. 

AristosQueue wrote:

To make any actor that is not a QSM, you would need to do one or more of the following:

1. have something reach in from the outside to change its state (for example, share its state through a DVR with some other process) or
2. allow the actor to look through the queue'd messages sent and pick and choose the messages it wants to act on

I'm not following you at all.  Are you are essentially claiming a QSM is a "well-implemented actor message handling loop?"

If something reaches in from outside to change the internal state of an actor, that doesn't make it 'not a QSM,' that makes it 'not an actor' (in the actor-model sense of the word--you may still consider it an AF actor if it inherits from the Actor base class.)  One of the fundamental principles of actors is all data is transferred via messages.  Not meeting the requirement of being an actor means the thing isn't an actor.  "QSM" isn't even part of the discussion.

Most QSM implementation I've seen have external processes act on some sort of shared state variables used by the QSM.  (The most common being a global stop variable.)  Furthermore, many QSM implementations I've seen preview the messages on the queue.  Not one person I've encountered (other than you, just now) has ever said, "that construct uses shared state data and/or previews the queue; therefore it is not a QSM."

I fully agree both of these things are practices that will likely lead to problems.  I strongly disagree the community is on board when you claim either of these practices makes the construct no longer a QSM.

AristosQueue wrote:

All of which are possible with AF actors.  Macros are Batch Msg.

(I don't understand how these things being possible with the AF has any bearing whatsoever on how I define QSM, but whatever... I'll roll with it.)

No, macros are not batch messages, at least not from an actor theory standpoint.  Whether it's true in the AF depends on how you've implemented batch messages.  (I haven't looked.)

Macros, as commonly implemented in QSMs, rapidly enqueue a sequence of messages one at a time.  When writing macros developers usually expect the messages to be executed in that exact sequence, but of course since they are being enqueued one at a time there's no way (in general) to prevent some other actor from enqueuing a different message in the middle of the sequence.  Whether or not that matters in any particular situation depends on all sorts of details that are not well-understood. 

As you know, the solution is to create a new message that encompasses the entire seqeunce of desired tasks so there is no opportunity for other messages to get inserted into the sequence.  If the AF batch message is implemented in a way that prevents stray insertions (which I think it is) then it is not a macro in QSM-lingo.

AristosQueue wrote:

The Enqueuer has priorities.

I am aware of that, and I've said several times if someone needs a priority queue they should use the one you developed.  I am not objecting to priority messages (though I do believe they introduce complexity that is nearly always entirely unnecessary,) I am objecting to using the 'enqueue at front' feature to create priority messages.  That implementation is a dead end and does not scale at all.

AristosQueue wrote:

And actors FREQUENTLY send messages to themselves.

In AF terminology sending 'self-messages' seems to include situations where helper loops send messages to the MHL.  In my terminology sending a 'self-message' means having a message handling loop send messages to itself, as my comment indicates.  There is a huge difference between the two.  The former is necessary.  The latter is neither necessary, nor is it a practice I recommend others frequently use.  (Because it is all-to-easy to accidentally create a condition where the self-enqueued message *must* be the next message processed--which in the general case cannot be guaranteed--and it is very hard to verify that condition does not exist when there are many self-sent messages.)

[drjdpowell]

Daklu wrote:

If the AF batch message is implemented in a way that prevents stray insertions (which I think it is) then it is not a macro in QSM-lingo.

The "macro" term comes from the JKI-QSM template, which does satisfy the condition that "states" in the macro execute in order and with no possible external interference.  So the AF's batch message is a valid macro analog.

Daklu wrote:

In AF terminology sending 'self-messages' seems to include situations where helper loops send messages to the MHL.  In my terminology sending a 'self-message' means having a message handling loop send messages to itself, as my comment indicates.  There is a huge difference between the two.  The former is necessary.  The latter is neither necessary, nor is it a practice I recommend others frequently use.  (Because it is all-to-easy to accidentally create a condition where the self-enqueued message *must* be the next message processed--which in the general case cannot be guaranteed--and it is very hard to verify that condition does not exist when there are many self-sent messages.)

Self messages which are "things I need to happen now" are problematic; but those that are "things that should happen after any possible waiting external messages have been handled" are not.  A delayed message to handle some periodic task is an example of the later: something that explicitly does not need to be the next message processed.

Note, BTW that there is no reason in the AF to send self messages of the first type, as one can always call actor methods instead of writing messages, or even call the Do methods of your writen messages directly.  In many text/case-structure QSM designs this can't be done and thus people self-message actions that must execute next.

[Daklu]

drjdpowell wrote:

Self messages which are "things I need to happen now" are problematic; but those that are "things that should happen after any possible waiting external messages have been handled" are not.

I agree with you to some extent, but I don't think that's the best way to look at the problem of message sequences.  Let me try to explain...  Never mind... I spent four hours trying to type up an explaination and still have an incoherent mess of ideas.  The best I can do is right now is say you've correctly identified the two extreme ends of the spectrum, but it oversimplifies the issue and doesn't help identify whether the many messages that fall in between the two extremes are safe or not.  In any event, this discussion is a tangent of a tangent of the original discussion and if you want to continue it we should probably adjourn to LAVA.

drjdpowell wrote:

The "macro" term comes from the JKI-QSM template, which does satisfy the condition that "states" in the macro execute in order and with no possible external interference.  So the AF's batch message is a valid macro analog.

Short answer:

Allow me clarify my original comment.  "No, macros as understood by most traditional QSM programmers are not batch messages, at least not from an actor theory standpoint."

Slightly longer answer:

Your comment touches on a much larger discussion of the philosophy of language which isn't really appropriate for this thread.  Suffice it to say I am not claiming Stephen is using the term "macro" incorrectly in the absolute sense.  I am saying he is using it to describe a concept that is different from the concept traditional QSM programmers think of when they hear the term.

Batch messages replace macros (as understood by traditional QSM programmers.)  They address the use case macros are often associated with (sequences that must be executed as a unit), except they do it safely.  But to say macros (as understood by traditional QSM programmers) and AF batch messages are the same thing is confusing because they have entirely different functional behaviors, and that difference is what makes batch messages safe and macros (as understood by traditional QSM programmers) dangerous.

[mike-o-tronic]

I see where the rumors about "self-messaging" debates are coming from

So here my comment regarding the QSM:

I actually needed to think about what my definition of QSM is. When I asked I had a finite state machine on my mind, driven by a queue. Means you have well defined states, where transitions are triggered by elements in the queue. Then I was reading the paper about the QSM which defines it as:

Generally, a queued state machine is a LabVIEW programming method that sends commands and other data from multiple source points (i.e.. producer points), such as from user events and from one or more parallel processes, and gets these handled in one state machine process (i.e.. destination consumer point) in the order in which they were added to the queue.

I agree with AQ that from this point of view the question is "What else could you do other than a QSM?"! On the other hand I agree with Daklu, that this document feels "painful" because I totally miss in where they go from "...sends commands and other data" to queued states. The QSM as shown in the paper is to me more a Queued Command Processor (as shown in figure 1). So maybe the question should be "What else could you do other than QCP?"

I probably gonna look into the LAVA definition of QSM at some point, but so far it was to me more "queued states" either driven by data enqueuing (conditional state machine) or state request enqueuing (triggerd state machine).

Data enqueuing: Let's say we take an Actor just create Messages to write data and after each data write we run a method "SM" which determines what to do depending on my current data values. It's not the states that are queued here but the data, which defines the states.

State request enqueuing: The SM stays in it's current state until it's asked to change to another state. When asked the SM checks depending on data values and current if the transition is valid or not. If transition is valid, the state changes if not, nothing happens or error returned. This is like commanding the SM to do something. The SM can decide if it's able to execute or not.

I also used combinations of both, where SM can change a state by data change or by request. But to me it was always by definition of SM that one state leads to another via transitions, which are part of the state machine! When I think about really enqueuing states it gives me goosebombs. I might be wrong but I feel like it contravenes the principle of a state machine and is nothing more than enqueuing commands.

And here another one regarding self-messaging:

And I'm talking about MHL to itself... I think it's similar to recursion. It can be very helpful but also very dangerous. But just because you need to be careful when using it, I wouldn't stay away from it. And an interruptable sequence is a really good example for that as shown is the first posts here or the "state 2" command example from the QSM paper. The "state 2" command initiates a sequence 2->3->4, which is repeated until some other command will replace the elements in the queue. To me that's totally fine as long as it's under my control that command "state 2" is not send another time while the repeating sequence is active. Similar in the AF I could have a flag, which avoids reinitiating the sequence or avoid continuing the sequence including 3 and 4.

[drjdpowell]

Daklu wrote:

Allow me clarify my original comment.  "No, macros as understood by most traditional QSM programmers are not batch messages, at least not from an actor theory standpoint."

Do "traditional QSM programmers" use the "macro" term?  In reference to LabVIEW I've only heard it in the JKI template, which is consistant with "batch" messages (and other uses of "macro" in computer science, I believe).

The only other comment I can offer on the issue is that people often mix up two different "queuing" uses: sequencing code blocks, and handling events/messages.  On handling an event one must return to a state where one can handle the next (arbitrary) event.  But a code block can easily have (possibly quite strict) conditions on what can or must happen before or after it.  Using the event/message queue to sequence your code blocks can lead to bugs, when events occur inside code block sequences.