User login

Navigation

archives

My system uses message passing in it's highest level abstractions and this does provide concurrency, however, the Actor Model is only a specific instance of message passing. The Actor Model has the following characteristics:

(these quotes are from Wikipedia)

send a finite number of messages to other actors

create a finite number of new actors

designate the behavior to be used for the next message it receives

The use of the word "finite" is redundant when used in a CS context as everything is finite except for a bug called an infinite loop. Although my message passing can create new "actors" and send multiple synchronous or asynchronous messages, it is only through changing the persistent state of my actors that one message can effect another (point 3). In general, my system tries to keep interaction between messages to the same "actor", to a minimum.

The Actor Model specifically says that messages can arrive in arbitrary order while my system will always deliver messages to the same actor in the order they were sent.

The Actor Model didn't guarantee that the recipient of the message actually exists or that they got the message. My system makes sure that the message can be delivered before it is sent or an error message is the result.

The Actor Model didn't queue multiple messages addressed to a single actor. Without this system guarantee, how would you know if your messages that normally work, would always work regardless of the work load? With the Actor Model, you would have to create your own protocol to make it useable. My system queues all messages sent to all actors.

In the Actor Model, the "return address" for a message was left up to the person sending the message. The Actor Model only incorporated messages in 1 direction rather than having automatic return messages and the choice of "synchronous or asynchronous" messages. My system incorporates 3 different kinds of message right in the syntax of the language so that it is obvious what kind of message is being sent.

The Actor Model, as defined by Mr Hewitt in 1973, said it was "inspired by physics including general relativity and quantum mechanics". I created all the rules of my message passing without any knowledge of the Actor Model or in fact what kind of message passing other languages use. My inspiration was just common sense and programming experience. I am not taking credit for inventing message passing but I am saying that message passing is a normal and obvious Computer Science concept rather than a Mathematical one, regardless of who first published the idea (sort of).

My recommendation is that the word "Message Passing" be used rather than the "Actor Model" when talking about message passing and concurrency UNLESS all the features of the Actor Model are used.

I have to say up front that I am not a big fan of recursive function calls. I have created them only about 10 times in 35 years of professional computer programming. My plan was to not allow recursion in my language but I have come to realize that some algorithms are best described in this manner.

In C, recursion is implemented by putting all local variables and the return address on the stack. This causes a few problems for me in that if you don't stop the recursion then you blow up the stack. The number of local variables and the stack size determine when the dreaded "stack overflow" occurs which is not acceptable in my system as it must recover from all errors and continue to run. You also have to make sure your function unwinds the stack before you can exit and errors at arbitrary stack levels cause even more headaches.

I am well aware of optimizations for tail recursion which turns recursive syntax into just an internal loop but my problem is actually with implementing real recursion.

My functions are implemented as rows of a table where calling a function is done by stacking the calling row. Each function includes a symbol table so there is more setup for a function than in C. All my function code is always reentrant so subsequent calls are quite quick. Once setup, these functions stick around until they timeout. Putting hundreds or thousands of copies of these functions in my function table or allowing a recursive function to jeopardize my call stack is not an option for me.

A recursive call is a combination of stacked variables and a return address. I would be interested if anyone here has seen a simple language syntax that implements this functionality without actually using a function call. I would also like to have the programmer be able to directly test the level of the stack in their algorithm. Stack lists are an elementary variable in my language as are Maps that can contain any number of any type of variable. I could push a Map and a return address on a stack, for instance.