Subject: Re: Your CSP book Date: Mon, 5 Jul 1999 13:52:36 +0100 (BST) From: Stephen Jarvis To: Dear Maximiliano, > The most important one it's about the concept of state of a > process. Do the processes in CSP have state? No, is the simple answer. Unfortunately CSP does not have an intuitive concept of state. This is one of the major drawbacks and has been the source of much research for years. Some of the favoured approaches have been to merge Z (which is very much state based) with CSP. However, it all gets a bit complicated. > I thought CSP wasn't an state based formalism, Indeed, you are right. The only explicit state which you have in a processes is in the form of communication variables. This is effectively a 'local state' brought about by a series of communications. > but I can read in your book that one can use subscripts in > order to define the state of a process. Yes, that is right. It is not really feasible to have a formal language like CSP be useful without some more practical model of state. Using subscripts is now looked at as a simple way of adding state to CSP processes. It is certainly easier that using a Z/CSP type hybrid. > Is the state local to the process? Yes it is. So you have quickly spotted the drawback of this approach... > If one process want to inform > (partof) its state to an other one, should the former communicate that data > through a communication channel? This is one way to transfer state. It is also possible to pass state when further processes are called in a sort of 'pattern matching' manner. > Is the only possible way? I can also > infer from some examples that if process Q is part of the definition of > process P, then the state of Q is also (part of) the state of P, is it > right? It is like a programming language in that sense. If a process definition is local to another, then the scope of the state is over both processes. > How exactly is the pattern-matching between subscripts? For > example in > the case of sequences, must I assume the existence of a theory of > sequences like the one used in functional languages? Px:q > pattern-matches > with Pq? Yes, that is exactly right. This pattern matching is in fact stolen from the theory of functional programming. Using pattern matching is not as horrid as it might first seem. If you are dealing with a large state: Name Age Occupation Publications Wrap it up in a tuple (Name,Age,Occupation,Publications) which has an appropriate type (String,Int,String,[String]). Then use this type when defining processes: P(x,y,z,[]) = ... P(x,y,z,(a:as)) = ... Pattern matching is used to determine which definition of the process is appropriate. (This state can be subscripted or not - but I can not do this with this editor). > The last question concerns with use of subscripts. On one hand > you can > use subscripts for the state, and on the other hand one can use them for > enumerate processes. How can a machine or a human distinguish the > subscripts that are being used for enumeration than those used for state > definition? This is a good question. Unfortunately these subscripts have been rather abused and as it happens, are used to represent both enumerated processes and state. It is now pretty conventional to use definitions like P(x,y,z,(a:as)) = ... where the state is defined as a formal parameter to the process. The subscripts are then saved for enumerations. > I hope not to bother you too much with this questions, and I > wish you could answer me at least the first one. Not at all. It is a pleasure. Do contact me if you have any further questions. The book is OK. I think that it is the most practical CSP book on the market. The others seem pretty theoretical and practitioners do not find then as readable. Saying that, there are plenty of improvements which we could have made. Any feedback you have would be very useful. Sincerely, Stephen