Using the pi-calculus for systems building

I have not written here for so long. There have been too many activities, in research and in people's network, all these movements, they are moving rapidly. Here I just record my mail to a new industry colleague I was recently introduced, explaining in general terms the role of the pi-calculus as a basis of systems building with distribution. I hope it is of some use for those who wish to know about the pi-calculus and its usage.

........................

(omit preamble)

Your note is quite nice. I do not know much about the supply chain management: however I can see how each part will interact with each other from your description very clearly.

I think what you have done in this paper is to consider the systems design from the viewpoint of communication. That has been implicit in many (large) corporate systems, but only now this idea is getting explicit.

If you are serious in extending this idea, being informed by the pi-calculus, I think it may be useful to know a little bit about the different ways pi-calculus can be used. In fact already you used it, o model behaviours of systems through interaction. To proceed further, my modest experience with industry colleagues suggests some basic ideas about this calculus can be often useful. I do not wish to be long and bore you, so I will be very brief (for this vast subject!). I will be able to augment it in our later conversations.

* * *

The pi-calculus has two aspects. One aspect is that it is a tool to understand computation in general, including sequential programming languages, thread-based (shared variable) concurrency, distributed systems, Turing machine, lambda-calculus, synchronous systems, asynchronous systems. For example we can embed various programming languages without losing their structures and properties in this tiny calculus. For this, if you have not read yet, the following address by Robin gives a good summary:

http://www.cs.unibo.it/icalp/Lauree_milner.html

This aspect is deeply related to all other uses of the pi-calculus: but directly it is most relevant to scientists who wish to study computing. Many studies can be found in technical conferences and many results are being accumulated, though most may not be immediately relevant to systems building.

The other aspect of the pi-calculus is a fully expressive, but tiny, communication-based language with exact semantics, just as you used in your modelling of supply management. Thus it can offer a basis for various experiments on how we can model, program and validate software based on communication. As you may know, there is a general trend towards the use of communications in corporate systems. As an example, AMQP is an open standard for messaging (there are others). Messaging has been at the core of large corporate systems centring on e.g. IBM MQ, but we can now find its robust equivalent for free, changing the ways corporate applications are developed, enriched by so-called ESB. From the pi-calculus viewpoint, such a trend enables developers at large to think about software based on processes and messages.

In this context, we can think of the pi-calculus as a theoretical basis for experimenting various ideas, such as programming, modelling and testing software based on communications; validating such programs and models; and managing and controlling them. For example, the current development tools (starting from UML, to Java, to C++, taught all over the globe) often centre on classes and objects. Are they adequate for modelling, programming and validating software whose main mode of operation is communication of messages? If not, what alternative(s) can we provide to developers, from Chennai to London to Tokyo to New York to Paris? The pi-calculus, because it distills the full expressiveness of communication-based computing, including its richness and challenges, in its tiny syntax, offers a key tool upon which various efforts along this line can be based on, compared, and discussed.

* * *

Since I wished to be brief I needed to be abstract. The second aspect of the pi-calculus discussed above is a rich source of dialogue between practice and theories: I will be glad to have further conversations.

Best wishes,

kohei

Communication is a great glue

We have been working on theories of session types, and developing a language for session types. Working on session types and conversations (as in Scribble) is a real fun, since settling its status is not so easy. It is not a "technology" though it is a sort of technology. What is it? Is it for a "programming paradigm", such as "session-oriented programming" or "conversation-oriented programming"? Well I would surely like that kind of idea, and we have been having a lot of discussions, but one interesting thing is that, while these ideas are fascinating and surely worth pursuing, that may not be all.

This is because communication is a great glue. It is already a glue (people are using web's protocols often for that purpose, integrating applications). but its real power has not been fully exploited yet, high-level sessions (soon I will explain) and session types will play a central role when we combine different programming languages, different runtime, different abstraction levels, different applications, different virtual machines. So it cannot be only for a specific programming paradigm. By its very nature, sessions and session types, and in fact communications, are to be located between programming languages, between different runtime systems, between different levels of abstractions, between different operating systems, between different applications.

So sessions exist in and for such "betweens". Yes we can have pure session-oriented languages, this will be beautiful and will teach us quite a lot, but the true nature of sessions and session types lie in its sloppiness, its multiplicity, its power to connect the homogeneous and to connect the heterogeneous.

A high-level session is close to a session as we know in network engineering, a session in TCP, a session in SMTP, a session by cookie (well is that a real session? I know you are doubtful, I am too, but still it shows there is some need...), a session in DCCP, that is it, a session naturally comes about when you need control for your asynchronous messages, and you do need many kinds of control, for example flow control, either flow control of two ends (as embedded from the first in TCP) or more global flow control often centring such notions as TCP-friendliness (which is not a mystical notion at all, it is a notion like United Nations, but more effective).

So that is a session as found in network engineering. A high-level session differs from its network-level counterpart in the following two points:

1. It has a structure: it consists of communications of discrete messages, often typed, and is constructed by combining these communications through several basic primitives such as sequencing, local branching, recursion, loops, exceptions, etc.


2. It is a logical unit of interactions, abstracting underlying transport-level details (such as TCP connections), so that it can in principle survive transport failures, it can span over several TCP connections, or even over different protocols, etc. etc.

Of course we all know about the second point, this is what you find when you are chatting with somebody using say skype. But sessions lift them to a first-class programming concept, the idea being explored and materialised by Ray with Nobuko, backed up by a theory developed by Dimitris, Mariangiola and others. As to the first part, you can experience "structure" when you ever program with session types. This "structure" is where "types" in session types play the key role: types describe and assure structures, the best analog we find in usual programing languages is types in ML (Ocaml), Haskell, and to some extent, Java.

This is sessions and session types, or conversations and conversation types (we call high-level sessions "conversations" when we wish to be a little more friendly).

So we have sessions and session types, and, I repeat, though there can be something like "pure session typed programming", which I find fascinating, we also need a robust and impure concept, impure since it will be embedded in a diversity of programming languages, in a diversity of layers of implementations. And this concept should become so well-digested philosophically and descriptively, so effective in performance and in engineering, so well-understood in theory and systems, and so convenient to scribble with, that it will in the end become something you find mundane and matter-of-fact in programming, such as while-loop, if-then-else, etc. etc. Well the new constructs may need more care than these sequential counterpart in their introduction, but it should be as simple and as mundane, when they get finally used.

The diversity of the contexts where this simple notion can be placed, is staggering. Think of parallel computing. Andi and Ray are studying about sessions in parallel computing, where sessions are used in stateless, convergent, deterministic parallel computing. So this is sessions in the world of stateless computing.

Or sessions for servers, for example a server-side of Gmail, (well its client-side too), this is very stateful, if you save a mail, you want it to be saved, even if it has not been saved before, this is what we call stateful. This state, whose connection to interactions can be best understood using the example of List in Milner's textbook on CCS, where interactions and states are exactly and deeply related in just three pages using a very simple example, this state is what can make computation so rich and hard to control, and sessions are going to control it by articulating it by the program's interactional behaviour, either with outside or with other internal entities say threads. These are generally sessions in the world of stateful computing.

So sessions and session types will play many roles. It has its depth in a simple engineering desire, it has its theoretical basis in a magical formalism called the pi-calculus, as well as its theories of types, which in turn come from the lambda-calculus. And its engineering implications, including infrastructural elements which need to assist them, are deep and broad, of which only a little bit (but hopefully some of the key starting bit) has been explored.

Exploring its engineering and theoretical implications leads us to many thoughts, opening up the notion of computing into a broad universe of interactions, in practice and in theories.

kohei

Out of many, one

When I read the two books written by a politician who has just become the 44th president of United States, in particular the second book, I was impressed. Clearly he is a rare mind, rarer since he is in fact a thick-skinned politician.

Reading in detail his inauguration address delivered today, we may appreciate how he can convey a broad, clear vision for humanity in this global age (modulo his restriction as a president of one specific nation, which he embraces with understanding and determination) while at the same time carefully intending it to be practically effective. His words have both clear utility and deep truth, positioned in a broad historical context. In his message, utility strengthen truth: it was so in his address on race a few months ago, in this way those words are the truest of all, as are this time.

We may remember what Kant said: you should not only use another human being as a tool, but also treat him/her for his/her own sake. Utility is pragmatism, but idealism is also pragmatism. Both should come together.

He is going to serve the interests of one specific nation state called United States of America: that's his job. But this nation state has a special nature, and this gives her a special status in the world history at this point, which, paradoxically enough, now demands ideals unifying all nations on earth. In this context, USA has some role/duty, and without carrying out her duty, perhaps she may not survive. As a realist, that is where Mr.Obama can be effective beyond his national boundary.

But the main reason why Mr.Obama appears in this blog is because his key philosophy touches the central nature of distributed computing. He says (well an American coin does so too, but he also says):

"Out of many, one."

This is what distributed computing is about, that what looks like one is in fact many, and that  only by being many, this "one" becomes meaningful.

..... and this is also what the pi-calculus is about, why it starts from interactions at multiple locations, even mobile and located ones, and their compositions. In this way it is about the universe made from compositions of many disparate entities, that is why it can describe the diversity of interactional computation.

But what is the singularity of this modelling framework, in the context of distributed computing? Or indeed for the modelling of computation in general? That discussion we leave to our later posts.

Coming back to Mr.Obama, this fertile idea, "out of many, one", is not about many nations but about his nation and how it wants to be, at least for some time. His use shows it clearly, and indeed his speech often highlights the nation's fight against "others", which can be catastrophic for "others", especially if that is done by mistake, so to speak. But his way of communicating such fights, while (somewhat paradoxically) appealing to patriotism truly effectively, does indicate the breadth and depth of his understanding of where we human stand now. This understanding is going to be used for effective national and foreign policy of the united states of America. But, by way of his true realism, it also indicates something beyond the boundary of one specific nation. The history is moving (we may say one of the origins of this lies in Internet itself, in particular its two core foundations, TCP/IP and the notion of Inter-networking itself).

kohei

For our shared enterprise

When I am working on theories of conversations, what strikes me is not the fact new ideas just continue to come out (though it is true: out of me, out of my colleagues, out of many people, --- I note this is not birth without pains, all birth is with pain, here we need constancy in a series of births, that is the technology I am learning now) nor the fact that they are deeply based on theories of types for functions though with new effects and new forms (and again this is true: and I wonder if it is the case that it is only when one needs to face concurrency in earnest that types become so essential that nobody can ignore them, they become central to computing, even if its significant portion was developed by those people who love these strange animals called higher-order functions which may look somewhat Ecclesiastical to some --- but even in C we can use typed higher-order functions which is indeed very useful in practice).

What really strikes me is the fact that these ideas come out as if they are predestined --- as if these notions exist from the first, buried here and there to be discovered, and we are just doing a work of discovering. If I am permitted to "draw water into one's fields" (this is a Japanese idiom to excuse a positive remark about oneself, which is regarded in Japan a bad thing, in a way similar but subtly different way in Britain) they are born in perfection (though with some pain!), like Pallas Athena was born perfectly clad (or armoured?), they come out as if what we are doing is nothing: I am being used: this was out there from the first.

Of course this does not contradict the significance of a philosophical general grasp of what a conversation is and what it can be --- which is very human after all --- my dialogue with many academic and industry colleagues, --- for academic especially colleagues those I interacted with on session types, including Vasco, Kaku-kun, Kubo-kun, Mariangiola (my respect to her for her genuineness towards our profession and subjects, that purity in interest which can encourage people's best part), Marco, Dimitris, Ray, Andi, Nobuko, and many others, --- and industry interactions, especially earnest, concrete ways Steve and Gary work with so-called business protocols --- how enriching they are in the end! --- and prompted by visceral and yet deep grasp of distributed computation by Matthew Rawlings as well as his many examples, some strange (like the birthday present protocol and its variations) some quite business-oriented --- prompted me to think about this notion from the depth. From the real depth.

I am being driven. And this seems not solely because of the desire to communicate good findings to our colleagues --- which is by the way surely an honourable motivation and is further a socially useful one. It looks it pertains to another desire, more modest and hidden, a desire to understand this virgin territory, to explore this new terrain, --- that attracts me, since this realm, it is being born like Pallas Athena, is so rich in what it can give us, and it also seems to extend to a vast hinterland not known even vaguely now, though my modest talent prevents me from spelling full details of what may be out there.

My colleagues and I reached initial theories of session types without knowing the key philosophy --- the simplest philosophical observation --- what a session or conversation is, what it can be. But it also looks I knew about it --- since if not we could not have arrived at that shape (I know: the answer is that it is simply practicality that let me settle on there together with the depth of interactional computation distilled in the shape of name passing, that small but greatest calculus: and of course both of them --- this practicality, this name passing --- are still most mysterious). And I also know it is the recent dialogues with my colleagues which equipped me with what I believe to be key insights on session types and conversations. Without these dialogues nothing could have proceeded. Why did these dialogues come about? What made them possible? What brought Gary here, what brought Steve to CDL, what brought Matthew Rawlings to chair a crucial working group of an international standard organisation in this starting point of 21st century? Why Gregor Horpe had this inception that this is something worth calling with a good name? And why at this point at Microsoft they started this operating system project and how can they be so idealistic and moreover start to include even local branching/selection which is the core of session type discipline? And Cedric Fournet, one of the strongest process theorists, why did he get interested in session types? And what brought David Frankel, careful and knowledgeable, to think that some simple and basic change in a popular UML diagram may be possible, at least casually suggesting it?

We are here. And we are seeing something interesting ahead of us. Extremely interesting. We want to see it closely, catch it in our hands, taste it, marvel it from all different angles, come to know it deeply. We are such animals. It is in our DNA. It is worth exploring.

So let's explore. Let's join our forces for this exploration. And make computing more powerful (and yes faster, even faster for a given energy), more exquisite, more stream-lined, more clearly articulated, much much more dynamic (but controllable! if not how can we make it dynamic?), more powerfully and clearly and succinctly and as needed rigorously scribbable, freely moving from high-level sketch with a quick thick brush for hugeness of distributed systems to very fine drawings of individual parts, like drawing a large painting or creating a huge sculpture, it will be kinder to the earth, kinder to us, but can yield a great power if you master it --- "something rich and strange" --- it awaits us. The land is here. Let's work together.

kohei

A note on my old note

This is inside parentheses: I happened to find my immature old memo on a thin book on philosophy (from 2006!) in a web bookshop. It was not about my speciality and the writing was far from up to quality --- I had accidentally posted it after reading this beautiful book and asked the bookshop to withdraw it: and they said they would do so (at that time the site did not allow a poster to cancel such a post oneself).

I suspect it has been there for some time: if so I wonder why I was not aware of it. Now that I found that it has been there at least for some time I feel somewhat stupid to cancel it: after all it has already been public for a while, though I may in the end cancel it, after some time (I should say I spent only a few minutes in writing it, immediately after reading that book).

What I wrote there is not as clear as I'd like my writing to be nor will it be useful for others --- but I do not find the need to add to or retract from that old note, at least what I had written might be honest in its own way, except recording one point: the author of that book is known to be both a great scholar and a political personality; and I am learning about some basics of that social part, on which I wish to unequivocally admit that I am ignorant (that little book however does not refer to this political aspect directly). I am hoping that my learning on that topic, which is slowly proceeding, will be enriched by interactions with my new acquaintance(s) in the modelling and other worlds: since the conversations with sincere individuals whom I respect are what I value most when learning about an intricate historical topic, as well as the reading of those words left by good authors.

kohei

Von Neumann Machine: why we love it.

There are a couple of things we should not forget:

(1) Hardware is about software.

(2) The diversity of software, in size and in behaviour, is staggering: and they should coexist in the same machine.

(3) Not only coexist: they need to do so asynchronously. First they are often unrelated, which is the simplest way to be asynchronous: then they will interact, and an application may demand some service at any point during its run --- we cannot predict --- for example some part of JVM will become necessary abruptly; some part of GNU library; some part of OS functions. That's how your applications work, and that's why these services need always be prepared. They are interactional.

And this is precisely what a Von Neumann machine, combined with the good old operating system architecture, can offer us: numerous pieces of software running asynchronously which may be interacting from time to time (there are further internal interactions which are hidden: we shall come back to them in later posts). Its linear memory is ideal for putting the diversity of data structures and code laid out; combined with its engineering simplicity (and here we do not intend to give any scientific elucidation of this point but just note its beauty and effectiveness coming from its simple profile) we find what this abstract machine model offers us so convenient an ecosystem for software. While the current discussion does not intend to capture the key features of this machine model with precision (for example: what element in VNM enables this asynchrony?), we have at least obtained one way to view its value --- why it is being used and why it is so robust.

There is another thing we should not forget: this model has generality, and we can build our software infrastructure essentially on the same general abstract machine, even if different applications have different purposes, and different programmers program in so diverse ways, so this is just a corollary of Turing completeness, but we cannot avoid reality: software technologies built on a general hardware interface work --- even if it is built in a rather care-free, sloppy way.

Yes that is one of the secrets: without really really good notions of types, without really really good support of assertions, our software is working, in fact if you can program for Mac you can program for PC and you can perhaps program for a mainframe computer and you may even be able to program a Cray machine (well you should study a bit if your program is to run fast and yes this is reaching a different realm but anyway they are after all the same sort of computers!); and layers of layers of libraries, APIs, network stacks, OSes, applications --- they all simply work --- in some ways or other.

So here is the axiom:

if a system of software infrastructures is built on a general hardware architecture, even if they are built with human's fallible skills, and her/his usual sloppiness, without much support from types etc., they may still work. And perhaps it will work very well if we do build infra with good care about foundations.

As to the last part of the axiom above, my argument goes further: in the coming era of inherent concurrency we dearly need foundations if we wish to be effective. But let's not go too fast: let's stick to the problem at hand. In summary our machine model is good fot the diversity of software, in the sense that it gives us a good abstract basis for the flourishing ecology of software, and perhaps relatedly in that it is general, it works with the same general principle whatever your purposes are and whoever the manufacturer of your hardware would be.

And this machine is abstract not only as an abstraction but in its concrete origin: it was not born as an abstraction of the diversity of hardware but rather all these different kinds of hardware started from this abstract machine, first Turing then Von Neumann (in Turing machine we already find the same kind of programming as we do now for Pentium or ARM or PowerPC, an early beautiful example is by Kleene). And when the originators of RISC went back to Von Neumann its simplicity and generality are again made the best of.

So we have been using machine models which are based on an abstract machine with general principles (and therefore can be used for all different purposes) which are moreover based on asynchrony --- if I am to give a very crude summary of the pre-CMP era, this is it. And I believe these criteria are rather basic --- at least in the age computing is and software is intrinsic part of our society, part of our life --- I think these will continue to be basic principles, with some fluctuations. For example any hardware architecture (say a microprocessor with multiple cores) which does not satisfy these properties may not be a good engineering basis for future programming.

In other words: let's not compromise until we reach something everybody can agree on.

* * *

In spite of my promise in my last post I went into software. In fact I am finding I may need to dwell on it for some time, before we can discuss one of the root causes that is making our hardware model asynchronous.

kohei

Asynchrony

I humbly propose: this may be the most fundamental, or at least this may be the word which comes first if we are to choose only one, .... asynchrony, asynchrony in computation, and therefore, asynchrony in communication (two are the same thing, since computation includes communication inseparably, I hope you at least agree it is one way to see distributed computing, that's my hypothesis in these discussions, as I outlined in my previous post) (and by the way just in case you are worried: I am not forgetting about scribble, in fact we are in the middle of it).

Emphasising asynchrony does not mean for example we should assume a communication medium with unlimited bandwidth (and certainly not with zero latency!). And we wish to have different ways to analyse such a medium --- they may be modelled as "ether" separate from processes or formalised as a collection of processes. We may need a queuing model on some occasions. But these will come later and as needed: at this point we do not mind these aspects, we solely want computation to be asynchronous.

But what does it mean to be "asynchronous"? One may define the notion informally thus:

the potential for each distributed process to be able to work following its own local clock, as far as there is no need to be fed data from other programs and synchronise.

First of all, it is about the potential: and we want that potential as a key element embedded in the model. Second, "local clock" etc is not too good a metaphor: anyway it gives us some idea, that a local program can be left to compute on its own as much as possible. Third it says there is some need to exchange data and synchronise --- but not saying how. Not saying it is to compute a function. If it is computing a function --- well that is one way. But there can be other ways. And there are.

Why do we know? We have known about it from the study of process algebras which are about the universe of concurrent, communicating behaviours. And especially because of our study of the pi-calculus which miraculously captures a very rich variety of interactional behaviours, and, as interactions, a wide variety of computational behaviours, in its tiny syntax. And this wide variety --- for studying which one can use many ideas, such as separation which Palamidessi once used in her beautiful and celebrated result. So we know. There are many kinds of behaviours, all couched in a small calculus of name passing.

What is further fascinating to me ---- and this is the first thing which fascinated me in theory of computing and why I started to work on science of computing seriously --- is that this calculus has an asynchronous version, and it turns out to be a minimal meaningful kernel of this calculus.

This point was observed based on the work by Milner/Parrow/Walker in 1989, and later by Milner in 1990, and let's face it I also contributed in my small way and, as I wrote, this incidental observation fascinated me so irresistibly. Later I found Gerald Boudol discovered the same calculus concurrently (and completely independently), in the context of his Chemical Abstract Machine.

Coming back to behaviours --- so I can tell you we have a huge universe of computational behaviours, and many of these things are meaningful, certainly realisable, and they are not always computing functions.

But that is not enough. That fact I knew for long and of course had been known before me by others. What we needed to know in addition is what it means for behaviours to be functions. Then we know the ground --- by knowing the figure. Since if so we know there is more than the figure --- now the ground can be a figure in its own right.

A series of studies have clarified this, starting from an embedding of functions in processes by Milner, and I do not quote them since there are so many, but let me say studies on logic and games (as we call them in our community) play a fundamental role here. This line of studies is still a very rich field and will continue to be.

So --- to make a long story short --- there are many kinds of interactional behaviours which go beyond what compute functions. And for all of them asynchrony is a foundation, a starting point, even though they may constrain asynchrony in diverse ways. So what we see is messages going hither and thither asynchronously. It is wrong to assume order-preservation in the delivery of these messages a priori --- which does not mean we cannot have it based on some mechanism, but can you think of a Turing machine which embeds a notion of objects and classes? Or data structures? Or even procedures... That will make a bad model, a good execution model should have two properties: being simple, and being very simple. And perhaps the third: being very very simple up to the point it almost (or perhaps completely) flat. I know this does not sound anyway informative (I know that) so I promise --- if you are interested --- that we shall come back to this point later. For now it suffices to say that we start from asynchronous exchange of data which may not preserve order. And we do not go into further details here, since probably the party ain't started yet and it is too early to start eating (but is about to, I believe).

For now, we have mentioned several very basic properties. Incidentally the characteristics I observed above are close to what Matthew Rawings once told me --- or declared to me --- as what should be an abstract model for financial networks.

I am not related to money so much (which surely makes me deal with money issues critically sometimes). Neither in my life nor in my profession I feel intimate about how international financial networks carry trillions of dollars each day, that's a different world, anyway it is a huge network, billions of messages going hither and thither each day, distributed all over the world, and this cannot work synchronously, can it? It cannot be order-preserving, can it? So this is something I do not understand in terms of amount of money involved but can surely understand some basic aspects of it in terms of computation involved.

So this story is after all (partly but honestly) about scribble: "One of its primary application areas of this language is modelling of financial protocols." By the way Gary just wrote to me about identities in interactions --- which are a little different from asynchronously operating localities at the abstraction level we are exploring now, but are closely related, and are certainly one of the key subjects for scribble. That is another topic, we shall surely reach there in near future: for now, we need to think a little more about hardware, to cultivate our understanding of this "a" word further.

kohei

Into the imperative depth

Imperative, I am talking about Turing machines, I am talking about Von Neumann machine, I am talking about read and write, but I am also talking about distributed systems. That has been ignored. Models of distributed systems have been ignored: as a result things are not working. At various levels, but especially at deep architectural levels, be it the Internet or multicore computing.

What are distributed systems? Perhaps one simple axiom gives you some idea:

The only way one can know the state of a remote system is to communicate with it.

And another (related) axiom, this time about a general idea to make your program run fast:

Let your program make the most of the available network bandwidth.

In other words it is a good idea to overlap computation and communication since without communication computation cannot proceed: in fact it is best to regard communication (the process of messages being sent and passed and delivered) as part of computation. In distributed systems we can see this in Internet: and in computer architecture we can see this in Transputers.

You may realise we can shorten these two axioms into one:

Communication and Concurrency

That is we cannot have concurrency without communication (in effect). Communication comes first. This is what Robin Milner said in 1980.

Imperative computation has something weird. The most weird thing is it runs. Another weird thing is it seems to become more easily cooked when it is sequential but by itself it has a strong need for asynchrony and concurrency (on this we shall come back in a later post). In other words its usual outlook may be a bit different from what it really desires in its instinct.

There are several things which have not been working: one of these things is models of distributed systems. That is why we cannot see very clearly what is taking place in CMP, chip-level multiprocessing, that is to say things are happening asynchronously and concurrently inside a chip so we say it is multiprocessing and it is happening on a chip so we say it is a CMP. And we seem to be struggling about understanding what we are struggling about. We feel there are difficulties but we do not know what they are.

A bad thing is the same thing seems to be true with the direction of hardware... When transputers were designed there was a clear understanding of what they wanted and that was deeply achieved... The history did not go in the direction of transputers, it is true. And ironically (but in fact inevitably) the other history, which is the actual history we have experienced, again leads to this idea of concurrency and asynchrony for imperative computing. But if you do not know what you wish to do then what will you do? If only so-called marketing is in your mind you see what you believe to be real which is something immediately possible and desirable or at least looks possible and desirable which means it is an answer interesting to almost nobody when it is finally introduced to this world (that is to say we do not see the potential since marketing or at least bad marketing only sees what is visibly desired now, not what is possible, since for the latter one needs true imagination which is different from both a fancy forgetting hard reality or a conformism which again is unrelated with reality in effect). Let me add in a hurry I am not criticising ignorance of others, far from it, since I confess that I do share that ignorance with everybody, in the sense that I do personally feel a severe lack of understanding, which I hope we can make clear together or at least investigate into it.

I think we have forgotten what the Von Neumann machine is about, what struck Alan Turing on one rainy day 80 years ago which started this science, this engineering, this adventure.

(To be continued.)

kohei

How the world is born

I was in Oslo. I was in Reykjavik.

In these places I thought about how the world is born. For example the world of data. If everything is a sequence of zeros and ones then there are no data --- unless they come from data.

When you start to think there are numbers and characters and strings and instructions you start to have data and then you start to have records and tagged unions and objects and all that.

The world of interactions is born in the same way. There are always messages, asynchronously born, issued, exchanged, received, processed. This has been so for thousands of years. There are however nothing we can catch there, nothing on which we can build --- not yet. Only when you single out a streak, or a zig-zag, of messages, some collection of messages, and say "here is a conversation" and you now see not messages but a flow which makes up a conversation, that is, you only have to single out one collection of messages as a flow, as an exchange, that is when a conversation is born.

Then you have many conversations, just as you have many data.

That is how types come about. Types in their basic form are there to single out, and once you learn to single out, once you can de-lineate, put a circle on the ground and find the "figure" (hence the "ground" too) you say (and this is a violent act, in a philosophical sense) there are messages inside (so in fact this is the first time you have seen those messages) and there are messages outside of it, only at that time you start to have a type, since types are there to delineate and describe, you want to say this is a "number", this is a "function/procedure over numbers", a basic form of types is something which can never be separated from individualisation.

I know this part is subtle. I know I need concrete examples. Not today. Here I hurriedly record my further thought from Reykjabik.

Static analysis can make things right and there are many powerful methods: for that purpose we first need something to start with and that is not static analysis. Similarly assertions and logic however snappy your reasoning would be are not something you can ultimately rely on since there is nothing you can ultimately rely on --- when you think you are not relying on anything you are doing so based on some tacit understanding of a closed community (which may give you comfort but which does not give you clarity). No ultimate. So you need to rely on something which has an explicit act of starting. I do not know why this is like this but it is so.

Kripke, a great thinker, wrote about something similar --- about an act of naming. For many "names" no ritual of naming as he described may have actually taken place. What he meant is that it is an explicit act, even if an unconscious act, you communicate that decision of naming, even if one on the receiving side does not see that it is a decision. And how it was fitting for me to think about these acts in Reykjabik, in the world of volcanoes and barren lands, where we need to name, we need to delineate, since if we do not do so we do not have anything to cling to, we cannot (re-)claim a place for human.

(By the way that is why there are only few good names in science and they are what will remain. And science of computing is almost not science --- at least its subject is so new in comparison with what we know as natural sciences or even mathematical sciences. So it has very few good names --- of course we have many fashionable ones but good ones are rare).

And just as yellow is yellow and a dog is a dog we have data, and we reach delineation of the whole collection of messages --- in the past, now and in the future ---- zig-zags of interactions, flows of interactions, we say "here is a conversation taking place" and "this conversation has such and such structure" and I do not think I am proposing this as a new technology, I am describing how it has begun and how it is always beginning repeatedly, just as an act of naming is taking place every time everywhere every now-and-then, but let me tell you this at least, albeit in a low voice: I do suspect things begin like this since I have some recollection of seeing them taka place.

In fact how can you analyse if you do not have the target of analysis? How can you assert and reason if you do not have the target of assertion and reasoning? What do you reason? What do you assert? Of course you can leave things implicit ... but that may be a bad strategy, in the end. And what I am saying is something well-known in science: do not think clever ideas work, clever ideas never work, only deep understanding works. One thing we have known for a long time in science is all good ideas are accumulative and almost uninterestingly built up towards generality and uniformity.

But I am not saying we cannot have that moment of striking clarity, like when Turing wrote to his mother he had found something very different from theories by his contemporaries, that his theory runs.

And it ran, and is running. That abstract discovery (with others' subsequent contributions including and notably Von Neumann's) has led to what we know as computing. And quite a few decades after that discovery perhaps only these days we started to have theories which can describe and understand the meaning of that discovery as science. But that is another story.

I was in Oslo, I was in Reykjavik. Tonight I wrote a few lines from what I remembered there, as well as after I came back to Britain. I am a foreigner living on British soil, and perhaps a foreigner for ever wherever I live. But I invite you to this abstract topos, a forum, since neither is what I pointed out above about science telling us that we cannot enjoy a few conversations, dialogues --- this is the place friends can exchange ideas in a most abstract and most concrete way, in a way which is about something universal but which can only be done in a most personal way, as human has continued to do so since they found this way of conversing and as they will continue to do so as far as human's history lasts.

kohei

Clear, straight and masterful

I hesitate to restart this blog from such a post: and this is about a grim, grave social topic (in which I have had some interest). But perhaps all the more so, it shows the importance of good mind, of good argument, and, ultimately, of good communication (*).

http://www.washingtonpost.com/wp-dyn/content/article/2008/04/08/AR2008040802607.html

kohei

(*) And of a good "rhetorical" question...

The illness which Shakespeare dreaded

My colleagues ---

After time consuming examination of blood and height and weight and all that, it turned out that I have that dreaded disease which Shakespeare sang thus:

Thou cold sciatica, cripple our senators, that their limbs may halt as lamely as their manners

I have not recounted the story of Matthew Rawlings charing in ISO20022, in F2F in December, nor David Frankel giving ever more exacting remarks about various things (December/February), nor a recent joyful workshop, nor a planned workshop in Oslo, nor Tony Hoare's visit and what chat we have had, and of course how Scribble is going (or how Gary is proceeding with this), because of this: anyway I now know the reason.

Perhaps I will anyway write here about something harmless since I cannot think and do nothing intellectually consuming.

Modelling Objects, Modelling Processes (2)

Well I am starting to write this at 2:25 so I will be brief today. The following account is based on what I learned from David's draft discussions on the metamodel for UNIFI 2.0 even though my understanding may still be shallow. Communications from Matthew (especially his Pierce interpretation of message delivery) have also given me a fertile ground to start from.

And yet another source, an experience --- today I saw a piece of software which is up and running and which I may call the first genuine conversational/session programming working in the real world (not my creation). It is not only working: it is superbly working with every bit fully working. But on that perhaps a month or so later.

* * *

We were discussing about how we position processes

As I wrote last time if we wish to have a foundational model then we start from a process and its specialisation being an object.

So a class model will be about a process (or let us call it a conversant) and if a conversant is so special as to have only call-return then it is an object.

This works of course. But if two communicate they need messages. These messages are mostly passive (this is not the pi-calculus view: but is a practically relevant view I believe).

And components of these messages may as well be described by class models.

This is one of the reasons we may start from objects and classes. Then a process which converses should be a special kind of an object. That is

some objects are also engaged in "conversation". They may be called conversational objects.

A conversation is different from method invocation since it uses a channel: moreover we assume there are another "thread" in the interacting party and they converse even though they can interact in the "co-routine" fashion.

Note the idea of conversational objects above conforms to Maxims 1--3 we discussed in the preceding post.

Now an object can be engaged in a conversation as a result of being invoked: and an object can also be invoked in a conversation when it is born --- automatically after its "initial state" (in the state diagram sense).

Suppose Alice, Bob and Carol are conversing. A message Alice sends should belong to a class which Bob understands. That is there should be a class model which encompass both Alice and Bob --- or at least we wish to have signature (structure) compatibility.

OK so we have some picture. This can be written as a diagram. I did not start from a "user" in UML (though this is natural). Here a "class" can be considered as a "participant (actor) in a role". We may as well wish to have a company like Amazon in this picture. Say this is a rectangle part of a UML use case diagram (that system with which a User interacts). Then where is a rectangle?

Well why not to have a rectangle? Put it around Alice. Note Alice is now a class: so its instance converses and perhaps we can colour Alice since it is a conversational object. In many cases (if we use conversations for programming-in-the-large) this object may as well be an object which only does a conversation and no method invocation any more (Alice has this to say: "I do more complex things now so how can we go back to that simplistic model even though I do have nostalgia"). Perhaps we can colour its border with orange to say it is a class for a conversant object.

I will upload some diagram (hand drawn so please do not expect much) which shows an instance of this. For now note that we have here

• three rectangles (participants)
• a specific class model for each which may be rather deep in hierarchy
  
• a common "shallow" model (or models) for messages
  

I do not wish to say this is one class model articulated with three "local enclosures" for each participant: in general we do not need a common class model even for message components even though this may be very useful in practical concerns and if we can afford this may be good to have (if you can easily have transparency in some cases why not to have it --- especially given one of our current primary applications is a meta-standard for different protocols).

So perhaps we may as well have a common class model for message components? Another thing which can be useful is a notion of a role which one can consider is a way to relate two conversational objects by saying "these guys are the same" or "these guys are essentially the same except wearing different colours" (say). Note however we need to write down a conversation between these two conversants: they are from the same template (they are instances of the same class) but when they converse they should converse as different persons.

One possible way (I do not say the best, we need more examinations) is to have a class model and consider about "using" one class in two participants --- by sort of projecting relation. This means we can also make two roles related by a class hierarchy.

This means we can have the following different kinds of class models in our conversation diagram:

1. Individual class models for each participant (deep)
   
2. Common class model(s) for message components (shallow)
3. Common conversational class model(s) for common or related roles (shallow)
   

At this point I do not know how useful 3 above can be: that point as well as all points including the basic setup, we shall examine from now on through use cases.

Today I will finish here. In the next post --- perhaps tomorrow --- we shall think about how we can adapt several standard diagrams for conversaitons, starting from tje use case diagrams.

Modelling Objects, Modelling Processes (1)

Modelling with capital M: that is what I am thinking here.

UML centres on objects (consider the class models, which are a lynch pin of this whole modelling framework). What are differences between objects and processes?

Not processes in any difficult sense: we need to think of them since they are the entities who converse. We are trying to describe conversations, so we naturally need to have the ontology of conversants --- if ever we want our modelling framework to be wholesome. It may also be better to be clear that I am not talking about "business processes" here even though it is closely related. I am talking about processes as a central concept in modelling: that is my discussions are purely from the viewpoint of modelling concerns. We need to position it as a fundamental notion for abstraction and modelling.

As Robin Milner observed in his recent short note, modelling is about explanation. So a process explains --- some behaviour, some structure. What is a process, what does it explain, how does it differ from an object?

It's better to start from a process. A process is an entity which interacts. Here "interaction" means it exchanges messages: it sends messages and receives messages. That is what a process does. And perhaps we want it to have its own state. So here is a simple definition:

MAXIM 1: A process is an entity with interactional behaviour and its own internal state.

The use of the term "interacitonal" may not be common, we can call it "interacting", I did not use the term "interactive" since this term may sound as if it is about human interaction. No, a process will usually interact with another process.

But this looks like quite like an object: what is a difference? An object has:

1. attributes
2. methods

And this second item carries an object's behaviour, doesn't it? Here we come to the first key difference between processes and objects:

An object may interact by method invocation and return; processes may interact with the outside in more varied ways --- it will have a series of interactions part of which can even be done in parallel but whose interactions as a whole form a meaningful structure.

In other words processes are engaged in a conversation: and patterns of conversations include, as a very special case, a method invocation and its return (including an exception return). That is

MAXIM 2: the behaviour of objects as we know of is a special case of that of processes: that is, an object is a special case of a process.

Note here I am exclusively taking the modelling viewpoint: of course a process may be implemented using objects, but that does not concern us in the present inquiry. Here we are trying to find steps towards an abstract entity which can be a basis of modelling the kind of software which predominantly consists of mutually and concurrently interacting software --- and perhaps the development of such a kind of software may become a lynch pin of software structuring methodologies in near future.

The modelling viewpoint demands us to stipulate --- make it exist --- the minimum essential structure of an abstract entity we are now struggling to build. Incidentally Maxim 2 offers us a hint: if so we need the same thing as an object in a process. How should it be named? Can it be something readable from the outside just as an attribute of an object? Or should it be strictly local to that process? But let's be conservative, we can change it later, this is anyway an experiment, we use the same term as an object:

MAXIM 3: a process has its attributes whose content defines the current state of a process.

Now this is a decision: and a necessary decision for that matter. And we have two more things to think given Maxim 3, answering (or trying to answer, let's be honest) the following two questions:

1. Can a process get engaged in two or more conversations at the same time?
2. How about messages? Perhaps messages consist of objects? Then don't you need objects before processes?

I will discuss these points tomorrow: for the time being I just give yes-no answers (which are not answers we are seeking but gives us a starting point at least): for 1 the answer is yes, and of course this necessitates us to think about shared mutual data. This is the concern treated in a corner of UML (so-called "active objects": on which there are a lot to discuss) but will become a basic concern from now on. Exploring this topic may need some time. For 2, again (and perhaps surprisingly) the answer is yes: we assume the existence of objects as our prerequisite. In fact conversations need messages and messages should be defined from some components. Well we could have started this discussion from messages as our expert colleagues are doing now in UNIFI.

But that will also be a topic we shall treat later. For now we finish this initial part of an exploration.

modelling needs meta-modelling!

I finally came to know about this: and this is not a simple tautology (tautology is a proposition which is always true). This is practical.

We are talking about domain specific metamodel. And this is the key to the use of meta-modelling as I am now starting to learn from David's recent note as well as rereading of his book.

One simple way to see this is to think about naming (whose importance in modelling has been stressed since the ancient times --- it is even in Michael Jackson --- though my understanding on this matter came from Matthew Rawlings). Now naming has at least the following two purposes in modelling:

• to make something existent which has not been existed (well to be precise reify but I think this may not be too far fetched)
  
• to make this stage prepared for future usage esp integration but also for maintenance and evolution and all that

So names are important especially for integration: but how then can we make uniform naming useful for integration?

One of the well-practiced answers is a dictionary, a dictionary of terms and conceps which are used in modelling. But this means a dictionary should cross over individual model elements, that is it should be at a meta-model.

From a different viewpoint, modelling can easily be lousy. And even good models are hardly useful except when they are equipped with useful helping infrastructure, including model transformation, assertion checking, automatic template generation, etc. (consider MOF transformations David discussed in his book). Without such infrastructure we do not have a good use of models themselves except as the means of communication --- but even the latter becomes much much more efficient with the use of metamodels which govern and guide them.

And this has a direct relevance to the design of Scribble --- even though it is a general-purpose language for describing interactions (well it is domain-specific in the sense that it is about interactions, but as such it is general purpose, and from the viewpoint of MDA too general-purpose --- so we do need be ready for domain specificity --- and here am I revealing too much? As it is reflected on Scribble's design we shall report on this and other columns).

NB: I am sorry updates this blog are not done so much recently: this is because I am busy in two fronts: (1) logics for interactions (motivated by both foundations and from Matthew's ingenious *short* treatise); and (2) understanding (meta)modelling to be reflected onto the design of the language. I also confess I am writing many technical papers, since to communicate something new one needs to prepare people's minds --- on this point perhaps we can discuss later. But on scribble, our main topic now is modelling and meta-modelling, which will prepare for other associated technologies such as DBC.

On modelling

We shall soon publish here and in other places a compilation of examples in scribble (an updated version). But a recent news I wish to report is that I am learning aboug modelling in UML sense in practice --- from David's writings and from ongoing discussions in WG4 (I am lucky I could listen to the first-rate modelling experts and domain experts engaged in actual modelling through conversations).

As an interim report I found that the modelling is about articulation of such things as:

• cardinality (n-m relationships)
• part-of relationship
• subtype relationship

.... all these kinds of relationships among entities. And by stipulating these relationships it is defining basic ontology of software to be made, or of messages to be exchanged.

So a modelling defines existence. That is why naming is so important in this endeavour.

This gives us the following observation, apart from my interest in Scribble: this level of "basic-ness" is needed if we are to introduce specification of interactional behaviour at the core of the modelling framework. I mean, at the same level as class models and associated diagrams.

This new element should be, if to be introduced, for defining the basic ontology of behaviour.

In other words and more concretely, I want the kind of technical discussions currently being carried out in WG4, or (in case you are not there) that standard modelling steps when we build entities and their relationships one by one, to be done at the level of interaction behaviours --- about the rules of exchange of messages.

Of course through the current discussions I am now concious of the challenging nature of the ontology of messages themselves, which is already new to the world of modelling --- and my (perhaps not too short) experience in the world of theory can easily let me see the value of having true experts in such technical works --- since they know the most important thing is to start from basics and to have a lucid understanding of it, gradually one by one: what a pleasure to see this unfolding in real-time!

So --- albeit, or all the more because of, my personal interest coming from scribble --- I will for the time focus on the understanding of ontology of messages by listening to these conversations. Why not, this is most exciting, I am learning a new attitude to the understanding of computation.

Copenhagen 2

Just in case this is of any interest to you, this is the abstract of the talk on logics I gave in Copenhagen. My thanks go to Lars Berkdale and Thomas Hildebrandt for hosting my talk.

Title:
An Observationally Complete Program Logic for Higher-Order Functions

Time and Place:
October 3rd, 11:15-12:30, ITU Copenhagen

Abstract:
If you have a program and run it, then it usually shows some behaviour. This may take the form of interactions with a display, a printer, or communication ports. More closely looked, its main interactions may be with an operating system, libraries and other software. Anyway it has a certain behaviour, which can be useful, can be disastrous, or can be enjoyable.

A program logic allows us to describe such software behaviour using logical assertions. It often also enables syntactic derivation of valid descriptions. Such a logic may as well have a semantic basis, in the sense that its assertions discuss all and only observable behaviour of programs. One of the well-known logics with this property is Hoare's logic for first-order imperative programs, developed on the basis of Floyd's assertion method.

This talk is about extensions of Hoare logic to higher-order functions. Extending Hoare logic to higher-order functions (which also underlie such popular languages as Java) has been known to be one of the subtle issues for decades: this work uses ideas from the pi-calculus to develop such an extension. The logic allows clean, precise description of higher-order behaviour and has several strong completenesss properties. In this talk, I will illustrate core ideas of the logic using simple examples, discuss its completeness properties and their proof methods, position them among related works and its extensions, and point out several remaining topics.

[end]

Copenhagen

It was a great visit --- Nobuko and I went to ITU last week.

First night we were roaming around Kongens Nytorv. Then we happened to walk into a placecalled hviids vinstue --- this should be since I kept a card --- and this was a place where a lot of locals are drinking and singing, and the man who looked like an owner is playing a piano.

I may not say he is a master. But he clearly had a musical soul. It was unmistakable.

There are two ladies who were taking care of the place, aperitif is good and food is ample and simple if not exquisite. A basic danish food which is edible. Many locals, as I wrote, and even somehow two local british --- one with a strong welsh accent --- were there, one of whom has his portrait on the wall, I think he is an old customer.

We also have a black singer who roamded into the house, all sang Danish songs and this master with a music spirit, an old man who was fat and bold and not with a great voice but so deeply driven by his inner urge to sing so you cannot help joining (if you knew Danish) it was one of the most welcoming nights we could have in a foreign city.

We can discuss about another restaurant but I will leave it for another occasion.

* * *

By the way Matthew sent me a mail about Physiognomy --- what was it about? Is it a new idea about asynchrony? He did find another asynchrony in communication recently. He is a man of asynchrony. He also calls telephone "telephonum".

So another question: did Romans use telephone?

[added a couple of days later: it turned out that he wrote "teleplenum" which means a conference via telephone, so this is simply my misconception. It also turned out that "telephonum" has some useful meaning but anyway he (nor Romans perhaps) did not use this word.]

* * *

I am currently too occupied with a few absorbing (one of which not so unrelated to scribble) subjects my colleagues and I have been working on so could not proceed with scribble: but Gary is proceeding with the design of 10 subjects --- 10 google docs we share --- at this moment. I will join soon. A basic part of this language will be complete in a close future. Well almost *now*.

Apologies

I have been so lazy: I cannot believe it.

What is happening?

Well many new findings: and discussions: and I think we shall have a roadmap soon.

But in this blog I will proceed one by one, illustrating each construct through examples.

Because of the difficulty and subtlety of our goal, because of the beauty and simplicity we want, because of the coverage of the descriptive tools we are making, it is best we proceed one by one.

Since interactions are everywhere and since many people seem to be approaching this idea from many angles --- from the observation that transaction is too restrictive for huge systems; from the observation that sharing and using financial protocols together is really beneficial for users; from the obvervation that we should share the infrastructure for message passing since in business we deal with messages not call-return; and from the need to describe applications and even operating systems as concurrent modules communicating with each other --- it does seem a good paradigm for describing interactions is being desired.

A paradigm --- or abstraction: we surely need a good abstraction or abstractions to articulate, model and describe, as well as building such interactional systems. And tools. And rules. And of course good implementation ideas. Everything. But we need some abstractions to start from.

A conversation is only one of possible such abstractions, a modest proposal from us and some of our friends. We recall it was once named session: it was also named contract; it was also named protocol. All these names give one side of this idea. Whatever it is there seems to be something which may be usable here: something concretely usable, at least for some purposes, for scribbling interactions nicely and clearly. Scribble is an experiment to create a new piece of a descriptive tool (or a family of tools) based on this abstraction.

It is for scribbling: so it should work with a simple setting of pencil and paper: but of course it will make the best of all software tools and artifacts and infrastructure we can avail.

And starting from a smallest conversation which is just one-time interaction done alone, and reaching a conversation which consists of 10 million messages or even more (in the large scale this is a norm in international financial protocols such as SWIFT; and in the minuscule level this is again a norm in on-chip interconnect which easily allows 1 million message passing in a second), we have many conversations and its phenomenology (or zoology if you like) never ceases to surprise this one of the humble designers of scribble. These are what we should capture and I now realise it is a fascinating journey we are now going through.

Today I finish here: I will continue with the choice example in the next blog. There are some who have new examples --- which we may be introduce when here is a chance. Let's also treat it here. Scribble is about a conversation so it is not surprising we are starting have several conversations. And conversations are never just one way: ideas are merged and interwoven and will lead to further budding ideas. This blog is just a record of such conversations surrounding scribble.

channel or port: a problem of English

I have not posted for some time: during that time I thought a bit about difference between port and channel starting from a chat with Matthew which let me recall what Gary cautioned me initially. For a channel one can read as follows from wikipedia:

Channel in communications refers to the medium used to convey information from a sender (or transmitter) to a receiver.

http://en.wikipedia.org/wiki/Channel_%28communications%29

Well this is what Gary and Matthew told me: a channel is a path between two endpoints rather than a place at which we send some datum. The latter is called port:

A port is an interface between the computer and other computers or devices. Physically, a port is a specialized outlet on a piece of equipment to which a plug or cable connects .... (etc.)

http://en.wikipedia.org/wiki/Computer_port_%28hardware%29

So a channel is a path whereas a port is an interface; and our declaration syntax:

channel chWorld @ World;

looks somewhat strange since a channel cannot be located at an endpoint World: and I can now see why Gary suggested I should use the term "to" as in:

channel chWorld to World;

but at that point I did not precisely see what he was getting at. And then Matthew said a channel is like English channel and it is not a place which you throw a message at and well it is quite right. And I realised a channel in the pi-calculus is a name for a channel and as such it is also a port since it is also an interface: it is a name. A name can be given to a path/medium (even perhaps a path which can be shared by many inputs and many outputs) or to a port and in such a basic formalism as pi all these different notions come out by different usage of names (just as objects and functions and streams and all that can be represented by specific ways of name passing in this calculus).

Perhaps more understandably, one may also say a name in the pi-calculus is a name of a channel: and if we regard that channel's input capability is fixed to some process then it becomes a port of that process.

All in all the main point is we can use "to" if what we are declarting is indeed a channel, as we did above. Alternatively if it is to be a port which we wish to declare --- as the prefix "at" suggests --- then we may as well write:

port pWorld @ World;

Then we can write:

pWorld.greetings(string) from You to World;

which may not be so bad after all.

But if we have two participants which share a port to receive how does it look like?

port pWorld @ {World1, World2};

So pWorld is a port --- an entry point --- in which a message may arrive, to be received by either World1 or World2.Well this sounds slightly magical --- how can a port be placed in two disparate locations? --- and in fact it now sounds more like a channel.....

So may we come back to channel?

channel chWorld to {World1, World2};

Well this makes a better sense: chWorld is the name of a medium, a path, through which a message will be passed to one of these participants. We did extend the idea of "one sender one receiver" idea above, but a communication medium in computing can be more versatile than geographical ones and indeed this generality is a matter-of-fact in the pi-calculus (note however a receiver is almost always unique: we consider a single receiver a default and perhaps even prohibit multiple receivers in some class of applications).

And if "from" is not specified then it means (in principle) anybody can use that channel for sending his or her message as far as a protocol as a whole is well-formed. Here "well-formed" means we do not have a message mix-up as we have seen in Example (1) Asynchrony a fortnight ago (which is here) (by the way having multiple senders may not be so bad in comparison, this time the medium is something like having multiple inlets and a single outlet: we can visualise it as a filter: and of course we can also have a multicast channel too in which a message is always copied to each outlet).

OK so perhaps a channel is still a good idea and we are going to use "to" instead of "at" or "@" when we declare the receiver(s) of a channel: that looks to me more and more natural. But if you have any observations please let us know!

Example (11): one by one

I admit what I wrote yesterday was an off-topic --- something was complete so I got slightly relieved.

Anyway we prepare for auction protocols: now an auction has a lot of constructs in it (unicasting, multicasting, loop, perhaps a global escape, choice, ...) so perhaps it's a good idea to introduce each of the basic constructs one by one. Our simplest protocol so far is one for the "hello world":

protocol GreetWorld {

  participant You, World;
  channel chWorld @ World;

  chWorld.greetings(string) from You to World;

}

where we declare this is the protocol, we declare its name (GreetWorld), then we declare participants we shall use as pure names so that models and programs can bind later, and we declare a channel we use.

Recall @ indicates the locatedness:

  channel chWorld @ World;

says that (1) we use the channel chWorld and that channel is located at World: World is the participant who can receive messages from this channel.

When a channel is declared, it will not be bound to anything later: a declared channel is entirely a logical entity inside a conversation (if you are familiar with the pi-calculus it corresponds to declaring a channel with "new"). This is like a method name (selector) is a pure name and is logically independent from any external entities. Or perhaps better it is like a locally declared variable which gets generated when a method is called and discarded when the method returns. So declaring a channel as above means specifying this channel is local to a conversation which will materialise this protocol.

This is subtlety of channel, how it is different from participants, and that which is important when we consider a protocol which allows the description of unbounded conversation structure.

Once we have everything declared we can have an interaction --- we formally call this interaction signature as distinct from conversation signature, but let's be simple --- which is:

  chWorld.greetings(string) from You to World;

The interaction says You (in fact somebody who is bound to You) will send a greeting to World via the channel chWorld. As we have discussed, we are assuming asynchronous messaging which will travel through some network infrastructure --- that expanse. The phrases such as from You and to World can be changed heir positions so we can say
to World from You if you like. Sometimes uniformity does pay for a quick understanding though.

To leave no stones unturned let's see what this

  greetings(string)

which is the message You will send to World. Here greetings is an operator name --- or a selector, quite like a method name --- and string is its argument type. Like method names, operator names are internal to a protocol. So a message (logically) in this interaction will/should consist of an envelope which is this operator name and its content which is a string.

But what is the use of this operator name? In OOPL we had a method dispatch table and we need to go to an appropriate code: but how does the operator name have use in interaction? Just as the mechanism of dynamics in OOPL, logically or as embodied in the design of VM (in the sense of JVM, not VM as in Xen), this operator name is closely tied to a key mechanism of conversation-based interaction which is a finite state automata which governs conversation behaviour. In brief an operator name serves as a transition label in FSA. So when a state in a FSA has several choices it is different labels which are used for this purpose. Of course logically (just like method names) it serves as a way to indicate what this message is about.

We shall come back to this point later. Here we note there is a simple way to go without an operator name and it is using a type name instead of an operator name, like (presenting the whole interaction):

  chWorld.string from You to World;

where we specify only the type, not a selector. This works well especially when you are sending a specific message type as in:

  chWorld.Greetings from You to World;

In such a case the name Greetingsserves as both the operator name and the message content.

To this topic we shall also come back later. I think this is enough as detailed examination of these basic constructs.

My original purpose was to introduce the next most basic constructs, sequencing and choice, after I briefly examined what we introduced already, but this prelude took long: I will continue with sequencing and choice in a new post, perhaps a couple of hours later.