Z++ and Robotic Communication

It seems like technology leaders are hoping for a Shakespeare who could write Romeo and Juliet with only half of the English he used. They limit their champions to Java, then BASIC or something like that, and then they eagerly await an impossible miracle. After all, even miracles that actually occur like Romeo and Juliet are relative to circumstances.

Perhaps someday robots will exceed Turing’s expectations and will be bored in carrying out a conversation with us. For now, however, our robots communicate by means of exchanging data with predetermined structure. The hurdle stopping us from achieving miracle software in robotic communication is not in the nature of the communication itself. Instead, we need a medium in which our Hugo and Shakespeare can develop such poetic software.

We must believe that there are software Hugo and Shakespeare out there as witnessed by the great software we are enjoying today. These software poets have written almost all the poetry that could be written within the existing linguistic abstractions available to them. In order to appreciate the challenge, imagine Hugo having to write an entire page for each of his lines of poetry, and still not be happy with his work.

Looking at history of mathematics, we see that Set Theory of Cantor and later the notion of Abstract Space by Frechet gave birth to modern mathematics in the hands of poet mathematicians. Thus, technology leaders are either unaware of the part of our history that relates to them, or prefer to live in denial. I suppose it is a combination of both.

An engineer writes his poetry in a programming language. So, what kind of abstractions will help our poet developers in achieving their goal of creating software for robots to exchange data in a manner that we can interpret as robotic communication?

Consider n robots attempting to accomplish a task. Each robot will have a name or something like that in order to be addressed by other robots. For simplicity, we refer to each robot as a node, and the name of the node will be its IP address. Note that this is an illustration of an abstraction and we will use the terms robot and node interchangeably.

Suppose robot M (that is, the node at IP address M) wishes to say something to robot N. Before M says anything it must get the attention of N. Also, M is busy doing something and cannot simply stop, say something and wait until it hears back from N, at least not every time that M needs to tell N something. In the same vain, N can talk to M when it needs M to do something for helping it.

We speak in patterns like Subject Verb, etc. We are able to understand a statement that does not quite follow an expected pattern. However, it takes a second or so to make sense of what we have heard. That means there is a low-level communication that expects fixed patterns, and a higher-level that can map an out of order pattern to its correct form. For now, we are only interested in low-level communication with regard to robots. That is, the pattern for data to be exchanged must be predetermined or the hearing robot cannot use the data transmitted to it.

The low-level pattern for robotic communication is a list of data types as in a function signature. Two robots M and N can communicate using a pattern if both are aware of the pattern. So now we need to investigate suitable linguistic abstractions to facilitate expressing these notions in the context of a program. We illustrate these ideas using the approach taken by the Z++ language.

The hearing robot N needs to know what patterns it is capable of accepting (understanding). So, an engineer needs a way of expressing this matter. In Z++, N learns its patterns by registering them in a hears(…) specification, as follows.

hears(signal, type_1, …)

In above statement, signal is effectively the name of the pattern, and the list of types is the actual pattern. We can think of the statement as, when a process executes the statement it learns the pattern. Thus, robot N is only capable of understanding all the patterns that it registers via the hears(…) specification.

Now robot M can talk to N using the Z++ tell statement, as follows.

tell N, signal, data_1, …

The first argument of tell is the name or the IP address of robot N. This is followed by the name of pattern and the actual data to be sent to N. However, the tell statement initially asks N if it recognizes the pattern by sending it the signal and the types of the data, but not the actual data. This gets the attention of robot N and enables M to decide whether or not to send the data. In programming terminology, if the tell statement fails at this point it raises an exception. Considering that Z++ exceptions can be resumed, an engineer is able to properly design the program to handle unusual circumstances.

Finally, N needs a way of receiving the data. The third and the last abstraction, does precisely that as follows.

hear signal, data_1, …

In the above statement, the data sent by tell statement are copied to the data listed in the hear statement. In this article we are not concerned about how intelligently N will use the data it hears from a tell statement. Our intent is to describe the abstractions that enable engineering poets to create their masterpieces.

In Z++ there are only three intuitive statements, which also help the compiler to trap many types of errors. That is the minimum number of abstractions needed for designing an understandable program that deals with robotic communication.

Now we can reiterate what was said at the beginning of this note. Removing the three abstractions mentioned here forces Hugo to write a page for a lot of his lines of poetry, and still feel discontent. In programming context discontent translates to uncertain about the behavior of the program. In particular such complex programs are formidable to debug. However, debugging three abstract statements can even be done by plain code walk-through.